The following call flow illustrates recording:
1. The voice gateway receives a setup indication and hands the call to a generic VoiceXML document.
2. The generic VoiceXML document requests a customized VoiceXML document from the VoiceXML server based on incoming call information (ANI, DNSI, RDN, and so on).
3. The VoiceXML server creates a customized VoiceXML document based on the call information provided a nd sends it to the gateway.
4. The gateway executes the document, which prompts the user to record a voice message.
5. The gateway records the message and stores it in local RAM with G.723.1 and G.711 u-law encoding.
6. When recording is complete, the user is prompted to review the message, or to submit the message to the VoiceXML server. It is also possible that the user can simply hang up.
7. When the user submits the voice mail message, the gateway’s VoiceXML browser submits the voice message as an .au file to a specified URL using the HTTP POST method.
The VoiceXML application must be able to handle the case the user hanging up before choosing to submit the voice message.
8. When the VoiceXML server receives the message, it stores the message in the appropriate mailbox.
9. When the voice message is successfully stored, the application instructs the media stream process to delete the local copy of the voice message.
10. The VoiceXML document disconnects the call.
<cisco-data> Element
The <cisco-data> element allows an application to load data from a server for handling a call. It allows voice applications to send and receive information from an external server when answering and transferring calls.
For call center applications, the VoiceXML <transfer> element is limited because it can only inform the HTTP server if the call does not connect because of:
• Busy tone, or
• No response from the called party, or if the call disconnects because of:
• Connection hangup, or
• Maxtime limitation.
VoiceXML 2.0 does not support an event when the <transfer> connection is made and the two parties start talking to each other. However, this limitation can be overcome by using a Cisco VoiceXML hybrid script in which the Tcl script performing the transfer can use the <cisco-data> element to send a GET or POST HTTP request to a web server.
The VoiceXML interpreter running on a gateway uses the <cisco-data> element to post data to a server, and receives that data back from the server without transitioning to a new VoiceXML document. The <cisco-data> element occurs as executable content, or as a child of <form> or <vxml>. It has the same scoping rules as the <var> element. If a <data> element has the same name as a variable declared in the same scope, that variable is assigned a value retrieved by the <data> element.
If the name attribute is specified and the data is not retrieved, the VoiceXML interpreter throws an error
event error.badfetch.http.nnn to indicate a fetch failure.
Note • Headers from HTTP responses are not available to a VoiceXML script.
• The <cisco-data> element supports only text messages. It fetches strings from a server and does not handle binary data. If binary or null data is encountered in a response, the information returned to the VoiceXML interpreter is truncated. For example, “My data is <binary data> received on Tuesday” is truncated to “My data is.”
• Data received is truncated if it exceeds 20 KB.
The attributes of <cisco-data> are:
• src
The URI specifying the location of data.
• name
The name of the variable that contains the retrieved data. If this field is deleted, data can only be sent to the server, not retrieved.
• expr
The URI specifying the location of the data. The URI is dynamically determined.
• method
Similar to the method attribute of the <submit> element in the VoiceXML 2.0 specification.
• namelist
Similar to the namelist attribute of the <submit> element in the VoiceXML 2.0 specification.
• enctype
Similar to the enctype attribute of the <submit> element in the VoiceXML 2.0 specification.
• fetchhint
Similar to the fetchhint attribute of the <submit> element in the VoiceXML 2.0 specification.
• fetchtimeout
Similar to the fetchtimeout attribute of the <submit> element in the VoiceXML 2.0 specification.
• fetchaudio
Similar to the fetchaudio attribute of the <submit> element in the VoiceXML 2.0 specification.
• maxage
Indicates that the document is willing to use content whose age is no greater than the specified time in seconds. Compare to max-age in HTTP 1.1, RFC 2616. The document is not willing to use stale content, unless maxstale is also provided. If not specified, a value derived from the innermost relevant maxage property, if present, is used.
• maxstale
Indicates that the document is willing to use content that has exceeded its expiration time. Compare to max-stale in HTTP 1.1, RFC 2616. If maxstale is assigned a value, then the document is willing to accept content that has exceeded its expiration time by no more than the specified number of seconds. If not specified, a value derived from the innermost relevant maxstale property, if present, is used.
DTD for <cisco-data>
<!ELEMENT cisco-data EMPTY> <!ATTRLIST cisco-data
src %uri #IMPLIED name NMTOKEN #IMPLIED
expr %expression; #IMPLIED %cache.attrs;
%submit.attrs; >
Example
This example shows the use of <cisco-data> in posting information to a server and receiving that data back from the server.
In this example:
• Variables a and b are assigned values. The variables and values are sent as avpairs in the body of the HTTP message.
• The HTTP server that receives the data sent to it is identified by the src attribute.
• The namelist attribute identifies the list of variables that are sent to the HTTP server.
• The HTTP method is the POST method.
• The received data is the body of the message received in the response from the server, and is stored in the MyData variable.
• The HTTP server does not support multipart data. In the <cisco-data> element, the data assigned to the variable name can be submitted back to the server for processing. However, Cisco IOS release 12.3T only supports the “multipart/form-data” type for <submit>. The enctype must be enctype= “multipart/form-data” if <cisco-data> is to be submitted back to the server.
<vxml version="2.0"> <form>
<var name="a" expr="123"/> <var name="b" expr="456"/> <block> <cisco-data src="http://townsend.cisco.com/cgi-bin/rama.tcl" name="MyData" method="post" namelist="a b"> </cisco-data> </block> <block>
<log> Yes. DATA received successfully. <value expr="MyData"/>
</log> </block> </form> </vxml>