SIP Interface to VoiceXML Media Services
Extracted elements (29)
Although RFC 3960 prefers the Application Server model for early media over the Gateway model, the Gateway model is used here because forking — the primary issue with it — is significantly less common when issuing requests to VoiceXML Media Servers: they respond with 200 OK within hundreds of milliseconds, making them unlikely forking targets. Additionally, no media packets are generated until ACK receipt, eliminating the ringing tone generation problem.
For outbound calling, Flow IV from RFC 3725 (third-party call control) is recommended in conjunction with the VoiceXML Session preparation mechanism. This avoids callee-experienced delay, sidesteps timing difficulties from VoiceXML document fetch time, and is IPv6 compatible.
VoiceXML call transfer via REFER is NOT RECOMMENDED in networks involving Application Servers; instead, the Application Server should provide call routing based on data returned via HTTP or in the SIP BYE message. VoiceXML transfer is primarily suited to PSTN IVR Service Node use cases where no Application Server is involved.
Blind and bridge transfer semantics using REFER (RFC 3515) are designed to be compatible with standard IP/PSTN gateways. The consultation transfer uses the Replaces: header (RFC 3891) for compatibility with the attended transfer flow defined in RFC 5359.
Certain applications may pass large amounts of data via Request-URI parameters, causing the INVITE to exceed network MTU. Implementations must use a transport appropriate for larger messages (e.g., TCP) or pass data indirectly (e.g., a session identifier key used to retrieve data from an HTTP server).
The fixed user part 'dialog' in the Request-URI ensures compatibility with RFC 4240 ('Basic Network Media Services with SIP'), which first defined this convention and is widely adopted by existing media servers. This document extends the RFC 4240 dialog interface.
A VoiceXML Media Server MUST support encoding of expr/namelist data in the message body of a BYE request sent as a result of VoiceXML <exit> or <disconnect>. The Content-Type header in a BYE containing expr/namelist data MUST be set to application/x-www-form-urlencoded;charset=utf-8. Non-ASCII characters are UTF-8 encoded with %HH escaping.
For audio-only applications, G.711 mu-law (RTP payload type 0) and A-law (payload type 8, RFC 3551) MUST be supported. The VoiceXML Media Server MUST support SRTP (RFC 3711) for RTP media streams including RTCP. DTMF events (RFC 4733) MUST be supported; when the UA does not indicate RFC 4733 support, the server MAY use audio stream DTMF detection instead.
If the Request-URI does not conform to this specification, the server MUST return 400 Bad Request. If a URI parameter is repeated, the request MUST be rejected with 400. If no 'voicexml' parameter is present and no default is used, the server MUST return 400 and SHOULD include a Warning header with code 399. If the VoiceXML document cannot be fetched or parsed, the server MUST return 500.
If VoiceXML call transfer is supported, the mechanisms described in Section 6 MUST be employed. For consultation transfers, implementations MUST NOT use RFC 4488 to suppress the implicit subscription associated with the REFER message, since the NOTIFY sipfrag response is required to determine transfer success or failure.
Implementations MUST at a minimum include the Call-ID header in the session.connection.protocol.sip.headers associative array. Header names are converted to lowercase keys; multiple fields of the same name are combined into a single comma-separated value.
The VoiceXML Media Server MUST allow the media session to be modified via a re-INVITE and SHOULD support the UPDATE method (RFC 3311). It MUST be possible to change streams between sendrecv, sendonly, and recvonly as per RFC 3264. Media session modification does not affect VoiceXML application execution except that recognition during hold results in noinput timeouts.
The VoiceXML Media Server MUST support the sips: scheme to protect confidential information passed in Request-URI parameters. This is mandated in Section 2.1 and reinforced in Section 9.
The VoiceXML Media Server MUST support the standard SDP offer/answer mechanism of RFC 3264. If no SDP offer is present in the INVITE, the server will make an offer in the 200 OK response listing its supported codecs.
The VoiceXML Media Server MUST unescape URI parameter values exactly once before using them or exposing them to VoiceXML applications. Double-unescaping would corrupt values that are themselves URL-encoded (e.g., a VoiceXML URI that contains encoded characters).
Upon receipt of a BYE in the context of an existing VoiceXML Session, the VoiceXML Media Server MUST send a 200 OK response and MUST throw a 'connection.disconnect.hangup' event to the VoiceXML application. If a Reason header (RFC 3326) is present, its value is provided via the '_message' variable in the catch element's anonymous variable scope.
Blind transfer is initiated by the VoiceXML Media Server via a REFER message (RFC 3515) on the original SIP dialog, with the Refer-To header containing the destination URI. On 2xx response to REFER, the server throws connection.disconnect.transfer and terminates the session with BYE. Non-2xx responses map to specific VoiceXML events (e.g., 404→error.connection.baddestination, 405→error.unsupported.transfer.blind).
Bridge transfer creates a small multi-party session: the VoiceXML Media Server sends an INVITE to the Callee and mixes Callee RTP with Caller RTP. The server can perform hotword detection on the Caller stream; a match causes near-end disconnect (BYE to Callee). If Callee issues BYE, the transfer item variable is set to far_end_disconnect; if Caller issues BYE, connection.disconnect.transfer is thrown.
Consultation transfer (attended transfer, RFC 5359) resembles bridge transfer but RTP streams are not mixed. The VoiceXML Media Server sends a REFER to the Caller with a Replaces: header (RFC 3891) referencing the Callee dialog, causing the Caller to directly call the Callee. Success is determined by a NOTIFY with 200 OK sipfrag; a non-2xx sipfrag causes the transfer item variable to be set to 'unknown'.
session.connection.protocol.sip.requesturi is an associative array of URI parameters from the initial INVITE Request-URI. ccxml-param and aai-param values are evaluated as JSON values; others as strings. The array's toString() returns the full Request-URI. session.connection.aai and session.connection.ccxml are aliases for the corresponding requesturi array entries.
Standard VoiceXML session variables are mapped from SIP headers: session.connection.local.uri from To:, session.connection.remote.uri from From:, session.connection.redirect from History-Info (RFC 4244), session.connection.protocol.name to 'sip', session.connection.protocol.version to '2.0', and session.connection.protocol.sip.headers as an associative array of SIP headers (lowercase keys).
The SIP Request-URI for VoiceXML media services MUST use the fixed user part 'dialog'. Seven URI parameters are defined: voicexml (URI of initial VoiceXML document), maxage, maxstale, method (get/post), postbody, ccxml (JSON value), and aai (JSON value). Parameters in re-INVITEs are ignored.
VoiceXML Session Preparation: a media-less SIP dialog is established by sending an SDP with no media lines or by answering the server's offer in the ACK with all media ports set to 0. The VoiceXML application does not execute until a re-INVITE establishes an active media session.
IANA registered six new parameters in the SIP/SIPS URI Parameters registry under the Specification Required policy (RFC 3969): maxage (no predefined values), maxstale (no predefined values), method (predefined values: 'get'/'post'), postbody (no predefined values), ccxml (no predefined values), aai (no predefined values). All reference RFC 5552.
Exposing a VoiceXML media service at a well-known address increases exploitation risk (e.g., triggering billing events). The VoiceXML Media Server is RECOMMENDED to authenticate requesting endpoints and authorize per local policy using standard SIP mechanisms (RFC 3261). To mitigate DoS attacks, it is RECOMMENDED to time-limit VoiceXML application execution.
For data confidentiality, the VoiceXML Media Server MUST implement sips: and https: schemes in addition to S/MIME message body encoding as described in RFC 3261. SRTP (RFC 3711) MUST be supported to provide confidentiality, authentication, and replay protection for RTP media streams including RTCP traffic.
VoiceXML Session lifecycle: on INVITE receipt, server sends 100 Trying and fetches the VoiceXML document; 200 OK indicates document fetched and parsed; application execution commences on ACK receipt. For session preparation, a media-less INVITE (empty SDP or ports set to 0) defers execution until a subsequent re-INVITE establishes media.
The BYE message body uses application/x-www-form-urlencoded;charset=utf-8 encoding. Namelist variables are converted to JSON values. The reserved name __reason carries 'exit' or 'disconnect' to distinguish VoiceXML <exit> from <disconnect>. If expr is used instead of namelist, the reserved name __exit is used. Example: 'id=1234&pin=9999&__reason=exit'.
The Request-URI parameters are formally defined as: dialog-param='voicexml=' vxml-url, maxage-param='maxage=' 1*DIGIT, maxstale-param='maxstale=' 1*DIGIT, method-param='method=' ('get'/'post'), postbody-param='postbody=' token, ccxml-param='ccxml=' json-value, aai-param='aai=' json-value. Special characters in dialog-param, postbody-param, ccxml-param, and aai-param values MUST be URL-encoded.