callxml elements

CallXML 3.0 Development Guide

<answer> element

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.

Note: systems might have auto-answer capabilities, where an inbound call is automatically answered. In this case an <answer/> will just be ignored. Also note that in order to use the <answer/> element, the auto-answer setting must be turned off for that application in the Voxeo Account Manager.

usage

<answer id="(element id)" test="CDATA" value-is="STRING" value-is-not="STRING">

attributes

id	Data Type: (element id)	Default: none - attribute is optional
	The new 'id' attribute in CallXML3.0 is applicable to all container and action elements. Specifying this attribute allows yet another level of control and event handling when events occur and are caught by the `<on>` element. When an event occurs, the handler will first check the event, and then verify that the handler has a handler specific to the 'id' attribute to execute. This allows the developer to plan a specific course of action for events based on where in the application that they occur.
test	Data Type: CDATA	Default: Optional
	The 'test' attribute is a new supplement to the CallXML markup that permits the developer to execute the contents of a container element, or action element, based on whether or not the specified condition is met. If the defined condition is met, then the code contained within the element is then executed. If the condition is not met, then the application resumes execution with the next sequential container container element in the document.
value-is	Data Type: STRING	Default: none - attribute is optional
	Another new attribute, 'value-is', grants the developer with the ability to perform conditional logic upon container elements, or action elements for the first time within the CallXML markup. The value specified in the 'value-is' attribute specifies a string to compare against any 'value' attributes. If the 'value' and 'value-is' equate to 'true', then the element specified will execute. If the value equates to 'false' then the element will be skipped during document execution.
value-is-not	Data Type: STRING	Default: none - attribute is optional
	Another new attribute, 'value-is-not', grants the developer with the ability to perform conditional logic upon container elements, or action elements, for the first time within the CallXML markup. The value specified in the 'value-is-not' attribute specifies a string to compare against any 'value' attributes. If the 'value' and 'value-is-not' equate to 'false', then the element specified will execute. If the value equates to 'true' then the element will be skipped during document execution.

code samples

<3.0 answer- test>

<?xml version="1.0" encoding="UTF-8"?>

<callxml version="3.0">




<do>

<log/>




<answer test="1=1">
<prompt>
this will be executed, as '1' is equal to '1'.
</prompt>
</answer>

<prompt>
If you got this far, then your call was accepted!
</prompt>

</do>

</callxml>

<3.0 answer_valueis_valueisnot.xml>

<?xml version="1.0" encoding="UTF-8"?>

<callxml version="3.0">




<do value="$session.callerid;">

<log/>
<answer value-is="4071112222">
<prompt>
this is executed when the caller ID is equal to 4071112222.
</prompt>
</answer>

<reject value-is="4072223333">
<log> *** CALL REJECTED *** </log>
</reject>

<prompt>
If you got this far, then your call was accepted!
</prompt>

</do>

</callxml>

<3.0 answer-id>

<?xml version="1.0" encoding="UTF-8" ?>
<callxml version="3.0">

<answer id="A1">
<wait value="3s"/>
<say id="P1">hey, we have answered the call</say>
<wait value="3s"/>
</answer>

<block id="B1">
<say id="P2">
Hi there.
Thanks for calling, but we don't really have any worthwhile content.
You should probably hang up now.
</say>
</block>

<on event="hangup" target="A1">
<log>** hangup occurred during A1 **</log>
</on>

<on event="hangup" target="B1">
<log>** hangup occurred during B1 **</log>
</on>

<on event="hangup" target="P1">
<log>** hangup occurred during P1 **</log>
</on>

<on event="hangup" target="P2">
<log>** hangup occurred during P2 **</log>
</on>

</callxml>

additional links

none

ANNOTATIONS: EXISTING POSTS

jpw

8/2/2008 9:23 PM (EDT)

i need to say this (sorry). it drives me nuts that on virtually EVERY online documentation like this one, the docs get all wrapped up on the whole test= target= stuff without in many cases showing different usage of the ACTUAL command. Seriously, when you are looking for docs on <xxxxx> you want to see the ins and outs of using that command that are relevant to it's ACTUAL purpose, not the same old test= target= stuff!

voxeoJeffK

8/2/2008 10:25 PM (EDT)

Hi,

Let me first say I can completely empathize with the frustration that can come from the research process and documentation. We greatly appreciate this type of feedback since it is certainly the best tool we can use to improve. In this case I think your frustration may come from the decision to keep documentation on each specific element tightly focused on just that element and its attributes. Attempting a more fully fledged example for each has a demonstrated tendency to "muddy the waters" by bringing in other elements and techniques not specific to the topic at hand. Fuller examples are kept to the tutorials and appendices.

In simplest terms the <answer> element allows conditional testing to determine if a call should be picked up, and then an execution path based from there. Is there a specific function or utility you are trying to accomplish that we can perhaps shed better light on for you?

Regards,
Jeff Kustermann
Voxeo Support