This element will "answer" or "pick up" the call. Any time a new call is received by a CallXML browser, it will use a browser specific mechanism to determine a URL from which to fetch an initial CallXML document to use for that call. However, the CallXML browser does not "answer" or "pick up" the call until this element is executed.
Assigns the value specified by the attribute value to the variable specified by the attribute var. As shown above, will assign the value "123" to a variable named "ttt". In addition to variables explicitly assigned by the CallXML markup, CallXML browsers may automatically create variables which contain information related to the call / session.
The <block> element is used to logically group action and event elements together, as well as providing the ability to loop the actions in the block a specified number of times. Note that <block> elements may be nested within each other to foster more structured CallXML interface code.
The Call element allows for new outbound calls to be placed to the specified address. The address is specified by the attribute value and is in URL format.
The root callxml element that contains all other elements. This element is required in any callXML documents.
Clears variable specified by the attribute var. As show below, will clear a variable named "MyVar". Effectively this works the same as <assign var="MyVar" value="" />
The digits buffer contains any touch-tone digits the user may have pressed before a CallXML action is executed. The 'cleardigits' element will clear the digit buffer of any queued digits.
This element allows multiple lines in separate sessions to be conferenced together so that the parties on each line can talk to each other simultaneously. The list of sessions to conference together is specified by the attribute targetSessions, and can be one more unique session identifiers separated by commas.
The <createconference> element is used to create a new multiparty conference for your callers. However, this element must also use it's sister element, <joinconference>, in order for callers to be connected to one another.
The <exit> element allows the developer to exit the session in question when it is executed in the callXML application. In short, it is much like an 'emergency brake' for a CallXML application. Note that in the event that an <exit> element is hit prior to a particular event handler executing, the <exit> will take precedence.
The getDigits element reads input touch-tone digits from the call and places them into a variable by the var attribute. This element is typically used for such tasks as gathering PIN codes, pager numbers, and anything else that involves multiple digits coming from the user.
This element can either:
Leap to another block of CallXML actions in the current file, by specifying value="#blocklabel", or
Perform an HTTP(S)/FTP to fetch a new CallXML document, by specifying value="url"
This element instructs the CallXML browser to "hang-up" or disconnect the call associated with the current session.
The <inputAudio> element combines the attributes and functionality of a <block> element, <playAudio> element, and a <recordAudio> element.
<inputdigits> is an element that combines the functionality and attributes of a <block> element, <playAudio> element, and a <getDigits> element. The intent of this element is to foster easy creation of scripts which prompt the user to enter variable DTMF digits such as pin codes, pager messages, and numeric values.
The joinconference element is used in conjunction with the createconference element to create multiparty conferencing. Specifically, this element allows you to join a caller to a specific existing conference.
The <log> element replaces the deprecated <simline> element for the purpose out outputting debugging text to the Voxeo logger.
Menu is an element that combines the attributes and functionality of a <block> element with a <playAudio> element.
This event occurs when a session determines that a call has been answered. This element is used as a handler to transition an action or event in a CallXML script after executing a <call> action.
This event occurs when the session determines that the attempted call cannot be completed because the dialed number is busy, a circuit is unavailable, a SIT tone was detected or other detectable call failure mode.
The <oncparesult> element is an event handler for Call Progress Analyzer, (CPA), related events/results.  A CPA event/result can occur at any time while the CPA is active.  When encountered, the CallXML browser will interrupt the current block of execution, and process the corresponding <oncparesult> handler.

Note that while the <oncparesult> tag does not have any 'parent' elements per-se, it is considered a 'stepchild' element of <call> and <onanswer> tags. Logically speaking, the only time that <oncparesult> can be executed is after a <call> that specifies specific CPA parameters is placed, and after the <onanswer> event handler is executed upon callee pickup.

Also note that only one 'type' may be specified per tag; the following code would be considered invalid, and should be expected to throw a fatal error in the application:


<oncparesult type="beep, machine">
  <log value="got a machine"/>
</oncparesult>
When certain errors occur an <onError> event is generated. This gives the CallXML developer a way to handle error conditions that may occur while CallXML actions are executing.
This event occurs when another session sends an external event to the current session.
This event occurs when a session determines that one side of the call has hung up. A typical use for this handler is to execute any necessary clean-up code.
This event occurs during user input if the length of the string of digits entered by the user exceeds the number indicated by a maxDigits attribute and a terminating digit has not yet been pressed.
This event occurs when the application has waited too long between digit entries or detects too much silence at the end of a recording session.
This event occurs during user input if the user takes more time than is allowed by a maxTime attribute to input their entire response.
Used for catching and handling term digit events as they occur in the call flow.
The <playAudio> element is used to output a .wav or a .vox file to the caller. Unless the caller takes some action, as (when used in conjunction with <getdigits>, for example),  the audio will repeat as many times as indicated for the parent <block> element.
The <playdate> element is used to render a given date to the caller via Text-to-Speech.
The playdtmf element allows the developer to play a sequence of dtmf tones to the call destination, (most often used when using a http token inititiated outbound call). This is useful for postdialing operations, where you may wish to programmatically navigate to a particular extension, or to navigate through a PBX menu. Note that when using this element, care must be taken to 'marry' a particular dtmf string to the specific menu that you wish to step through, as no two PBX menus are the same in regards to timing.
The <playmoney> element allows the developer to render a monetary amount to the caller via Text-to-Speech. The allowable ranges for this element are between '.00' and '999999999.99'.
This element is used to play a digit or number value to the caller. The format may either be specified as a digit output, or a numeric output.
The <recordaudio> element is used to record a caller's voice utterances for future storage and/or retrieval.
The <recordcall>element is a new element that allows the developer to record both sides of a call, recording the human and the application interaction to a wav file that is stored in the developer's Voxeo File Manager in the 'recordings' subdirectory.  <recordcall> can record to a stereo audio file and contains *two* 8-bit streams, (note that two 8-bit streams is not the same as recording in 16 bit).
The <reject/> element enables CallXML applications to reject incoming calls before they are answered.
This element will run/start a new session, and fetches a CallXML document to use for the session from the URL or URI specified by value.
The 'sendemail' tag is a new addition to the CallXML arsenal. This tag allows you to programmatically send an email to a user specified destination. Additionally, this new element also allows you to output debugging information in the body of the email, which is a very useful 'watchdog' feature that allows you to be alerted via email, whenever errors are encountered within the application.
The <sendevent> element is a tag that allows one session to send a user-defined message to another entirely separate session, such as when a <run> element has been used in the document.


Note: CallXML can only send events to other CallXML sessions on the same computer handling both sessions and should not be used a hosted environment.

Text is an element that is used to tell the CallXML browser to use a text-to-speech engine to read text contained within the element to the user.
This element allows multiple lines in a single session to be conferenced together so that the parties on each line can talk to each other simultaneously.
The wait element is used to instruct the CallXML browser to wait for a specified amount of time. This is most often used when you need to allow certain content within your code additional time to execute.
This element will "answer" or "pick up" the call. Any time a new call is received by a CallXML browser, it will use a browser specific mechanism to determine a URL from which to fetch an initial CallXML document to use for that call. However, the CallXML browser does not "answer" or "pick up" the call until this element is executed.
Assigns the value specified by the attribute value to the variable specified by the attribute var. As shown above, will assign the value "123" to a variable named "ttt". In addition to variables explicitly assigned by the CallXML markup, CallXML browsers may automatically create variables which contain information related to the call / session.
The <block> element is used to logically group action and event elements together, as well as providing the ability to loop the actions in the block a specified number of times. Note that <block> elements may be nested within each other to foster more structured CallXML interface code.
The Call element allows for new outbound calls to be placed to the specified address. The address is specified by the attribute value and is in URL format.
The root callxml element that contains all other elements. This element is required in any callXML documents.
Clears variable specified by the attribute var. As show below, will clear a variable named "MyVar". Effectively this works the same as <assign var="MyVar" value="" />
The digits buffer contains any touch-tone digits the user may have pressed before a CallXML action is executed. The 'cleardigits' element will clear the digit buffer of any queued digits.
This element allows multiple lines in separate sessions to be conferenced together so that the parties on each line can talk to each other simultaneously. The list of sessions to conference together is specified by the attribute targetSessions, and can be one more unique session identifiers separated by commas.
The <createconference> element is used to create a new multiparty conference for your callers. However, this element must also use it's sister element, <joinconference>, in order for callers to be connected to one another.
The <exit> element allows the developer to exit the session in question when it is executed in the callXML application. In short, it is much like an 'emergency brake' for a CallXML application. Note that in the event that an <exit> element is hit prior to a particular event handler executing, the <exit> will take precedence.
The getDigits element reads input touch-tone digits from the call and places them into a variable by the var attribute. This element is typically used for such tasks as gathering PIN codes, pager numbers, and anything else that involves multiple digits coming from the user.
This element can either:
Leap to another block of CallXML actions in the current file, by specifying value="#blocklabel", or
Perform an HTTP(S)/FTP to fetch a new CallXML document, by specifying value="url"
This element instructs the CallXML browser to "hang-up" or disconnect the call associated with the current session.
The <inputAudio> element combines the attributes and functionality of a <block> element, <playAudio> element, and a <recordAudio> element.
<inputdigits> is an element that combines the functionality and attributes of a <block> element, <playAudio> element, and a <getDigits> element. The intent of this element is to foster easy creation of scripts which prompt the user to enter variable DTMF digits such as pin codes, pager messages, and numeric values.
The joinconference element is used in conjunction with the createconference element to create multiparty conferencing. Specifically, this element allows you to join a caller to a specific existing conference.
The <log> element replaces the deprecated <simline> element for the purpose out outputting debugging text to the Voxeo logger.
Menu is an element that combines the attributes and functionality of a <block> element with a <playAudio> element.
This event occurs when a session determines that a call has been answered. This element is used as a handler to transition an action or event in a CallXML script after executing a <call> action.
This event occurs when the session determines that the attempted call cannot be completed because the dialed number is busy, a circuit is unavailable, a SIT tone was detected or other detectable call failure mode.
The <oncparesult> element is an event handler for Call Progress Analyzer, (CPA), related events/results.  A CPA event/result can occur at any time while the CPA is active.  When encountered, the CallXML browser will interrupt the current block of execution, and process the corresponding <oncparesult> handler.

Note that while the <oncparesult> tag does not have any 'parent' elements per-se, it is considered a 'stepchild' element of <call> and <onanswer> tags. Logically speaking, the only time that <oncparesult> can be executed is after a <call> that specifies specific CPA parameters is placed, and after the <onanswer> event handler is executed upon callee pickup.

Also note that only one 'type' may be specified per tag; the following code would be considered invalid, and should be expected to throw a fatal error in the application:


<oncparesult type="beep, machine">
  <log value="got a machine"/>
</oncparesult>
When certain errors occur an <onError> event is generated. This gives the CallXML developer a way to handle error conditions that may occur while CallXML actions are executing.
This event occurs when another session sends an external event to the current session.
This event occurs when a session determines that one side of the call has hung up. A typical use for this handler is to execute any necessary clean-up code.
This event occurs during user input if the length of the string of digits entered by the user exceeds the number indicated by a maxDigits attribute and a terminating digit has not yet been pressed.
This event occurs when the application has waited too long between digit entries or detects too much silence at the end of a recording session.
This event occurs during user input if the user takes more time than is allowed by a maxTime attribute to input their entire response.
Used for catching and handling term digit events as they occur in the call flow.
The <playAudio> element is used to output a .wav or a .vox file to the caller. Unless the caller takes some action, as (when used in conjunction with <getdigits>, for example),  the audio will repeat as many times as indicated for the parent <block> element.
The <playdate> element is used to render a given date to the caller via Text-to-Speech.
The playdtmf element allows the developer to play a sequence of dtmf tones to the call destination, (most often used when using a http token inititiated outbound call). This is useful for postdialing operations, where you may wish to programmatically navigate to a particular extension, or to navigate through a PBX menu. Note that when using this element, care must be taken to 'marry' a particular dtmf string to the specific menu that you wish to step through, as no two PBX menus are the same in regards to timing.
The <playmoney> element allows the developer to render a monetary amount to the caller via Text-to-Speech. The allowable ranges for this element are between '.00' and '999999999.99'.
This element is used to play a digit or number value to the caller. The format may either be specified as a digit output, or a numeric output.
The <recordaudio> element is used to record a caller's voice utterances for future storage and/or retrieval.
The <recordcall>element is a new element that allows the developer to record both sides of a call, recording the human and the application interaction to a wav file that is stored in the developer's Voxeo File Manager in the 'recordings' subdirectory.  <recordcall> can record to a stereo audio file and contains *two* 8-bit streams, (note that two 8-bit streams is not the same as recording in 16 bit).
The <reject/> element enables CallXML applications to reject incoming calls before they are answered.
This element will run/start a new session, and fetches a CallXML document to use for the session from the URL or URI specified by value.
The 'sendemail' tag is a new addition to the CallXML arsenal. This tag allows you to programmatically send an email to a user specified destination. Additionally, this new element also allows you to output debugging information in the body of the email, which is a very useful 'watchdog' feature that allows you to be alerted via email, whenever errors are encountered within the application.
The <sendevent> element is a tag that allows one session to send a user-defined message to another entirely separate session, such as when a <run> element has been used in the document.


Note: CallXML can only send events to other CallXML sessions on the same computer handling both sessions and should not be used a hosted environment.

Text is an element that is used to tell the CallXML browser to use a text-to-speech engine to read text contained within the element to the user.
This element allows multiple lines in a single session to be conferenced together so that the parties on each line can talk to each other simultaneously.
The wait element is used to instruct the CallXML browser to wait for a specified amount of time. This is most often used when you need to allow certain content within your code additional time to execute.