User`s manual

SIP User's Manual 486 Document #: LTRT-83303
Mediant 1000 & Mediant 600
An alternative method uses the AutoUpdate mechanism as described in Automatic Update
Mechanism. Both the vp.dat and segments.xml file that were previously created using the
APS should be located on an external storage server (HTTP, FTP). At startup, the device
fetches the files from the remote storage. By using the AutoUpdate mechanism, the device
periodically checks if new files are posted to the remote server and fetches these files.
The Application server communicates with the device using MSCML Requests (sent by the
Application server), as shown in the example below:
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<request>
... request body ...
</request>
</MediaServerControl>
The device uses MSCML Responses (i.e., sent by the device) to reply to the Application
server, as shown in the example below:
<?xml version="1.0" encoding="utf-8"?>
<MediaServerControl version="1.0">
<response>
... response body ...
</response>
</MediaServerControl>
To start an MSCML IVR call, the Application server (or any SIP user agent) sends a regular
SIP INVITE message with a SIP URI that includes the MSCML Identifier name. For
example:
INVITE sip:[e-mail] SIP/2.0
The left part of the SIP URI includes the MSCML Identifier string ‘ivr’, which can be
configured using the ini file (parameter MSCMLID) or Web interface (refer to ''Configuring
the IPmedia Parameters'' on page 242).
After a call is established, SIP INFO messages are used to carry MSCML requests and
responses. An INFO message that carries an MSCML body is identified by its content-type
header that is set to ‘application/mediaservercontrol+xml’.
Note that IVR requests are not queued. Therefore, if a request is received while another is
in progress, the device stops the first operation and executes the new request. The device
generates a response message for the first request and returns any data collected up to
that point. If an application is required to stop a request in progress, it issues a <Stop>
request. This request also causes the device to generate a response message.
The device supports basic IVR functions of playing announcements, collecting DTMF
digits, and voice stream recording. These services are implemented using the following
Request and Response messages:
 <Play> for playing announcements
 <PlayCollect> for playing announcements and collecting digits
 <PlayRecord> for playing announcements and recording voice
 <Stop> for stopping the playing of an announcement
The device sends a Response to each Request that is issued by the Application server.