RFC 5552
SIP Interface to VoiceXML Media Services
SIP Interface to VoiceXML Media Services 🎀
okay bestie, this is part 1 of 8 of RFC 5552, and it's giving standards track energy 💅 It's from the Network Working Group, published May 2009, and written by D. Burke (Google) and M. Scott (Genesys). It's a Standards Track document. The header doesn't list any Obsoletes or Updates line, so it doesn't replace or change any earlier RFC, as far as this part shows 🌸
Status of This Memo
okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🦋 If you want to know where the protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💖
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved ✨
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stand on the date this document was published. The link is http://trustee.ietf.org/license-info. Please actually read these, bestie, because they explain your rights and restrictions for this doc 🫶
Abstract
this doc describes a SIP interface to VoiceXML media services 🎧 Usually, Application Servers that control Media Servers use this protocol for pure VoiceXML processing. It's an adjunct to the full MEDIACTRL protocol and packages mechanism, so it's like the cute sidekick 👑
Table of Contents
1. Introduction ....................................................3
1.1. Use Cases ..................................................3
1.1.1. IVR Services with Application Servers ...............3
1.1.2. PSTN IVR Service Node ...............................4
1.1.3. 3GPP IMS Media Resource Function (MRF) ..............5
1.1.4. CCXML <-> VoiceXML Interaction ......................6
1.1.5. Other Use Cases .....................................6
1.2. Terminology ................................................7
2. VoiceXML Session Establishment and Termination ..................7
2.1. Service Identification .....................................7
2.2. Initiating a VoiceXML Session .............................10
2.3. Preparing a VoiceXML Session ..............................11
2.4. Session Variable Mappings .................................12
2.5. Terminating a VoiceXML Session ............................15
2.6. Examples ..................................................16
2.6.1. Basic Session Establishment ........................16
2.6.2. VoiceXML Session Preparation .......................17
2.6.3. MRCP Establishment .................................18
3. Media Support ..................................................19
3.1. Offer/Answer ..............................................19
3.2. Early Media ...............................................19
3.3. Modifying the Media Session ...............................21
3.4. Audio and Video Codecs ....................................21
3.5. DTMF ......................................................22
4. Returning Data to the Application Server .......................22
4.1. HTTP Mechanism ............................................22
4.2. SIP Mechanism .............................................23
5. Outbound Calling ...............................................25
6. Call Transfer ..................................................25
6.1. Blind .....................................................26
6.2. Bridge ....................................................27
6.3. Consultation ..............................................29
7. Contributors ...................................................31
8. Acknowledgements ...............................................31
9. Security Considerations ........................................31
10. IANA Considerations ...........................................32
11. References ....................................................32
11.1. Normative References .....................................32
11.2. Informative References ...................................35
Appendix A. Notes on Normative References ........................361. Introduction ✨
okay so VoiceXML [VXML20], [VXML21] is a World Wide Web Consortium (W3C) standard for making audio and video dialogs 🎤 It can do synthesized speech, digitized audio, recognition of spoken and dual tone multi-frequency (DTMF) key input, recording of audio and video, telephony, and mixed-initiative conversations. It lets Web-based development and content delivery paradigms work with interactive video and voice response apps, which is so iconic 💜
This document describes a SIP [RFC3261] interface to VoiceXML media services. Usually, Application Servers that control media servers use this protocol for pure VoiceXML processing. SIP starts a media session to the VoiceXML media server and triggers the execution of a specific VoiceXML application at the same time 🦋 This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.
The interface here builds on a mechanism for identifying dialog media services first described in [RFC4240] 🌈 It's been updated and extended to support the W3C Recommendation for VoiceXML 2.0 [VXML20] and VoiceXML 2.1 [VXML21]. It covers a set of commonly implemented functions and extensions, including VoiceXML dialog preparation, outbound calling, video media support, and transfers 🎀 It also defines VoiceXML session variable mappings for SIP, with an extensible mechanism for passing application-specific values into the VoiceXML application. And mechanisms for returning data to the Application Server were added too, so we're eating good 🍓
1.1. Use Cases
the VoiceXML media service user in this document is generically called an Application Server 🧚 In practice, the interface defined here is meant to work across a wide range of use cases. Several intended use cases are described below ✨
1.1.1. IVR Services with Application Servers
SIP Application Servers provide services to users of the network 💅 Usually there are several Application Servers in the same network, and each one specializes in a particular service. Throughout this spec, and without loss of generality, we assume there's an Application Server that specializes in Interactive Voice Response (IVR) services 📞 Here's a typical configuration for this use case:
+--------------+
| |
| Application |\
| Server | \
| | \ HTTP
SIP +--------------+ \
/ \ \
+-------------+ / SIP \ +--------------+
| |/ \| |
| SIP | | VoiceXML |
| User Agent | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+If the Application Server also supports HTTP, the VoiceXML application can be hosted on it and served up via HTTP [RFC2616] 🌸 But the Web model also lets the VoiceXML application live on a separate (HTTP) Application Server from the (SIP) Application Server that talks to the VoiceXML Media Server through this spec. It's also possible to store a static VoiceXML application locally on the VoiceXML Media Server. It can use the <data> mechanism from VoiceXML 2.1 [VXML21] to talk to a Web/Application Server when it needs dynamic behavior 🦋 Static VoiceXML apps get even more viable thanks to the mechanisms in Section 2.4, which let the Application Server make session-specific info available inside the VoiceXML session context. Main character energy 👑
The approach in this document is sometimes called the "delegation model." The Application Server basically hands off programmatic control of the human-machine interactions to one or more VoiceXML documents running on the VoiceXML Media Server 🫶 During those interactions, the Application Server stays in the signaling path, so it can respond to results returned from the VoiceXML Media Server or to other external network events. Iconic teamwork 💖
1.1.2. PSTN IVR Service Node
this document is meant to help VoiceXML work as a component of bigger systems and services 🌈 But devices that are completely unaware of this spec should still be able to invoke VoiceXML services offered by a VoiceXML Media Server that follows this document. A typical configuration for this use case looks like this:
+-------------+ SIP +--------------+
| |---------------------| |
| IP/PSTN | | VoiceXML |
| Gateway | RTP/SRTP | Media Server |
| |=====================| |
+-------------+ +--------------+Also, beyond invoking and terminating a VoiceXML dialog, the semantics defined for call transfers using REFER are meant to be compatible with standard, existing IP/PSTN (Public Switched Telephone Network) gateways 📞 Compatibility is everything, bestie 🦋
1.1.3. 3GPP IMS Media Resource Function (MRF)
The 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS) [TS23002] defines a Media Resource Function (MRF) that offers media processing services like conferencing, transcoding, and prompt/collect 🎶 VoiceXML is honestly perfect for offering richer media processing services in the MRF. In this architecture, the interface defined here corresponds to the "Mr" interface to the MRFC (MRF Controller). The implementation of this interface might use separate MRFC and MRFP (MRF Processor) elements, as per the IMS architecture, or it might be an integrated MRF, which is common practice 💜
+----------+
| App |
| Server |
+----------+
|
| SIP (ISC)
|
+----------+ SIP (Mr) +--------------+
| S-CSCF |---------------| VoiceXML |
| | | MRF |
+----------+ +--------------+
||
|| RTP/SRTP (Mb)
||ngl this diagram is super simplified and only shows a subset of the nodes usually involved in MRF interactions 🙈 It's worth knowing that while the MRF will mostly be used by the Application Server via the Serving Call Session Control Function (S-CSCF), calls can also be routed straight to the MRF without any Application Server involved 💅
Even though the above is described in terms of the 3GPP IMS architecture, it's also meant to apply to the 3GPP2, Next Generation Network (NGN), and PacketCable architectures that are converging with 3GPP IMS standards 🌈 Everyone's invited to the party 🎀
1.1.4. CCXML <-> VoiceXML Interaction ✨
Okay so, Call Control eXtensible Markup Language (CCXML) 1.0 [CCXML10] applications basically run the show 💅. They mainly provide services by controlling how Connections, Conferences, and Dialogs interact with each other. CCXML can support all kinds of dialog environments, but VoiceXML is the one people usually pair it with 🎀. CCXML is literally designed to support VoiceXML well, so they're besties 🫶. CCXML 1.0 has language elements that let Dialogs get prepared, started, and terminated 🦋. It also lets the dialog environment send data back, lets the dialog request call transfers that the CCXML application then responds to 🔥, and allows arbitrary eventing between the CCXML application and the dialog application that's running ✨.
The interface in this document can be used by CCXML 1.0 implementations to control VoiceXML Media Servers 💖. BUT, and this is a big but 😭, some CCXML features need eventing between CCXML and VoiceXML sessions that goes beyond what this specification defines. For example, VoiceXML-controlled call transfers and mid-dialog, application-defined events can't be fully realized with this specification alone 💀. A SIP event package [RFC3265] MAY be used alongside this specification to get that extended eventing 🌸.
1.1.5. Other Use Cases 🌈
Beyond the use cases we went through in detail above, there are a bunch of other intended use cases that don't get the full treatment, such as:
- Using a VoiceXML Media Server as an adjunct to an IP-based Private Branch Exchange / Automatic Call Distributor (PBX/ACD) 📞, possibly for voicemail/messaging, an automated attendant, or other capabilities 🧚.
- Invoking and controlling a VoiceXML session that provides the voice modality component in a multimodal system 🦋.
1.2. Terminology 📖
- Application Server: A SIP Application Server hosts and runs services, mainly by terminating SIP sessions on a media server 🖥️. The Application Server MAY also act as an HTTP server [RFC2616] when it's talking to media servers 💜.
- VoiceXML Media Server: A VoiceXML interpreter that includes a SIP-based interpreter context and the media processing capabilities needed to support VoiceXML functionality 🎧.
- VoiceXML Session: A VoiceXML Session is a multimedia session made up of at least a SIP User Agent, a VoiceXML Media Server, the data streams between them, and an executing VoiceXML application 🌸.
- VoiceXML Dialog: Same thing as a VoiceXML Session 🙈.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📜✨.
2. VoiceXML Session Establishment and Termination 🎀
Here's the plan for this section 💅: it covers how to establish a VoiceXML Session, with or without preparation, and how to terminate one. It also explains how session information gets made available to VoiceXML applications 🧚.
2.1. Service Identification 🪪
The SIP Request-URI is what identifies the VoiceXML media service 🎯. The user part of the SIP Request-URI is fixed to "dialog" 💖. This is done for compatibility with [RFC4240], since this document extends the dialog interface defined in that spec, and because existing media servers have widely adopted this convention from [RFC4240] 🫶.
Standardizing the SIP Request-URI, user part included, also makes interoperability between Application Servers and media servers better 🦋. It cuts down on the provisioning overhead you'd get if using a media server required an individually provisioned URI 😮💨. Basically, this document (and [RFC4240]) doesn't add any meaning to the user part. It just standardizes how targets on media servers get provisioned 💅. Also, since Application Servers, not human beings, are usually the clients of media servers, stuff like interpretation and internationalization doesn't apply 🤖.
Exposing a VoiceXML media service at a well-known address may make it easier to exploit 😭. So the VoiceXML Media Server is RECOMMENDED to use standard SIP mechanisms to authenticate endpoints, as discussed in Section 9 🔐.
The initial VoiceXML document is specified with the "voicexml" parameter ✨. There are also parameters that control how the VoiceXML Media Server fetches that document 🌈. Here's the full list of parameters this specification defines (heads up, the parameter names are case-insensitive) 📝:
voicexml: The URI of the initial VoiceXML document to fetch 🌐. This will typically be an HTTP URI, but it can use other URI schemes too, for example to point at local, static VoiceXML documents 🍓. Ifvoicexmlis omitted, the VoiceXML Media Server may pick the initial VoiceXML document some other way, like by applying a default, or it may reject the request 🙈.maxage: Sets the max-age value of the Cache-Control header for VoiceXML documents fetched using HTTP, as per [RFC2616] 🕰️. If omitted, the VoiceXML Media Server uses a default value 💜.maxstale: Sets the max-stale value of the Cache-Control header for VoiceXML documents fetched using HTTP, as per [RFC2616] ⏳. If omitted, the VoiceXML Media Server uses a default value 💜.method: Sets the HTTP method used when fetching the initial VoiceXML document 🛰️. Allowed values are "get" or "post" (case-insensitive), and the default is "get" 🎀.postbody: Sets the application/x-www-form-urlencoded encoded [HTML4] HTTP body for "post" requests (otherwise it's ignored) 🍭.ccxml: Specifies a "JSON value" [RFC4627] that gets mapped to thesession.connection.ccxmlVoiceXML session variable. See Section 2.4 👑.aai: Specifies a "JSON value" [RFC4627] that gets mapped to thesession.connection.aaiVoiceXML session variable. See Section 2.4 ✨.
Other application-specific parameters can be added to the Request-URI, and they're exposed in VoiceXML session variables (see Section 2.4) 🧚.
Formally, the Request-URI for the VoiceXML media service has a fixed user part "dialog" 🎀. Seven URI parameters are defined (see the definition of uri-parameter in Section 25.1 of [RFC3261]) 🔥.
dialog-param = "voicexml=" vxml-url ; vxml-url follows the URI
; syntax defined in [RFC3986]
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
json-value = false /
null /
true /
object /
array /
number /
string ; defined in [RFC4627]Parameters of the Request-URI in subsequent re-INVITEs are ignored 🙅♀️. A consequence of this is that the Application Server can't tell the VoiceXML Media Server to change the executing VoiceXML Application once a VoiceXML Session has started 😭.
Special characters in the dialog-param, postbody-param, ccxml-param, and aai-param values must be URL-encoded ("escaped") as the SIP URI syntax requires 🫧. For example, '?' (%3f), '=' (%3d), and ';' (%3b) 🌸. The VoiceXML Media Server MUST therefore unescape these parameter values before using them or exposing them to running VoiceXML applications 🔓. It's important that the VoiceXML Media Server only unescapes the values once, because the desired VoiceXML URI value could itself be URL encoded, for example 🧠.
Some applications may choose to transfer confidential information, so the VoiceXML Media Server MUST support the sips: scheme, as discussed in Section 9 🔒🫶.
Informative note: With respect to the postbody-param value, the application/x-www-form-urlencoded content itself escapes non-alphanumeric characters by inserting %HH replacements. So the escaping rules above end up further escaping the '%' characters, on top of the '&' and '=' name/value separators 🤯.
Here's an example. The following SIP Request-URI identifies the use of VoiceXML media services, with 'http://appserver.example.com/promptcollect.vxml' as the initial VoiceXML document, fetched with max-age/max-stale values of 3600s/0s, respectively 🎧✨:
sip:dialog@mediaserver.example.com; \
voicexml=http://appserver.example.com/promptcollect.vxml; \
maxage=3600;maxstale=02.2. Initiating a VoiceXML Session ✨
okay so a VoiceXML Session kicks off when the Application Server sends a SIP INVITE 📞 Usually the Application Server is basically a VoiceXML specialist 💅 At the very least it can act like a simple proxy and rewrite the Request-URI it gets from the User Agent into one the VoiceXML Media Server can actually use (see Section 2.1 🫶). Like, a User Agent might show a dialed number:
tel:+1-201-555-0123and the Application Server maps that to a directory assistance app on the VoiceXML Media Server with a Request-URI of:
sip:dialog@ms1.example.com; \
voicexml=http://as1.example.com/da.vxml🎀 Some header values from the INVITE sent to the VoiceXML Media Server get turned into VoiceXML session variables. Those are listed in Section 2.4 💖
When the INVITE lands, the VoiceXML Media Server sends a provisional 100 Trying 🦋 and starts fetching the first VoiceXML document. A 200 OK means the document was fetched and parsed correctly and it's ready to run. The app starts executing once the ACK arrives (unless the dialog is being prepped the way Section 2.3 describes 🧚). Note that the 100 Trying will usually be sent as soon as the INVITE arrives, per [RFC3261]. That's because the VoiceXML Media Server can't really promise the initial fetch will finish in under 200 ms 😭 Still, some implementations can guarantee response times to the initial INVITE, so they may not need to send a 100 Trying at all ✨
Here's an optional glow-up 🌈 Before it sends the 200 OK, the VoiceXML Media Server MAY run the application up to the first VoiceXML waiting state or prompt flush 🔥
A VoiceXML Media Server is still a SIP User Agent, so it can refuse an INVITE for all sorts of reasons 🙈 For example, if the SDP offer in the INVITE needs codecs the Media Server doesn't support, the Media Server should respond the way [RFC3261] defines. There are also some VoiceXML-specific errors, though:
- If the Request-URI doesn't follow this specification, a
400 Bad RequestMUST be returned (unless the URI is being used to pick other services that this specification doesn't define) 💀 - If a URI parameter shows up more than once in the Request-URI, the request MUST be rejected with a
400 Bad Requestresponse 🙅♀️ - If the Request-URI has no
voicexmlparameter and the VoiceXML Media Server doesn't choose to use a default page, the VoiceXML Media Server MUST return a final response of400 Bad Request. It SHOULD also include a Warning header with a 3-digit code of399and a human-readable error message 📝 - If the VoiceXML document can't be fetched or parsed, the VoiceXML Media Server MUST return a final response of
500 Server Internal Error. It SHOULD also include a Warning header with a 3-digit code of399and a human-readable error message 😩
Informative note: Some applications pass a ton of data to the VoiceXML dialog as Request-URI parameters 🍓 That can push the total INVITE size past the MTU of the underlying network. When that happens, applications and implementations must take care either to use a transport that handles bigger messages (such as TCP), or to pass the info another way, like supplying a unique session identifier in the initial VoiceXML URI and then using that identifier as a key to pull data from the HTTP server later on 🫶
2.3. Preparing a VoiceXML Session 🌸
Sometimes it's really useful to prep a VoiceXML Session before actually running it 🧠 A session that's already prepped is expected to start running with minimal delay once it's told to go 🚀
If the initial INVITE to the VoiceXML Media Server sets up a media-less SIP dialog, the VoiceXML application won't run after the ACK arrives 🙃 To get it going, the Application Server (AS) has to send a re-INVITE to set up a media session 💜
There are two ways to get a media-less SIP dialog. One is to send an SDP with no media lines in the initial INVITE. The other is to send no SDP in the initial INVITE at all. In that second case, the VoiceXML Media Server puts an offer in the 200 OK, and you respond with an answer in the ACK with the media port(s) set to 0 🦋
Once a VoiceXML application is running, a re-INVITE that disables the media streams (i.e., sets the ports to 0) won't otherwise mess with the executing application. The one exception is that recognition actions started while the media streams are disabled will end up as noinput timeouts 🙈
2.4. Session Variable Mappings 🧚♀️
The standard VoiceXML session variables get their values like this 💅
session.connection.local.uri: Evaluates to the SIP URI in theTo:header of the initial INVITE 🎀session.connection.remote.uri: Evaluates to the SIP URI in theFrom:header of the initial INVITE 🎀session.connection.redirect: This array is filled in from the History-Info [RFC4244] header in the initial INVITE, or it's otherwise undefined 👑 Each entry (hi-entry) in the History-Info header gets mapped into an element of thesession.connection.redirectarray, in reverse order. Each element's properties work like this:uri: Set to the hi-targeted-to-uri value of the History-Info entrypi: Set to'true'if hi-targeted-to-uri contains aPrivacy=historyparameter, or if the INVITE Privacy header includes'history'. Otherwise it's'false'🙈si: Set to the value of thesiparameter if it exists, otherwise undefinedreason: Set verbatim to the value of theReasonparameter of hi-targeted-to-uri
session.connection.protocol.name: Evaluates to"sip". This is meant to reflect SIP in general, and it doesn't tell you whether the media server was reached using SIP or SIPS procedures 🔐session.connection.protocol.version: Evaluates to"2.0"✨session.connection.protocol.sip.headers: This is an associative array 🗂️ Each key is the non-compact name of a SIP header in the initial INVITE, converted to lowercase (the case conversion doesn't touch the header value, though). If there are several header fields with the same name, their values get combined into one comma-separated value. Implementations MUST at a minimum include the Call-ID header, and they MAY include other headers 💖 For example:
session.connection.protocol.sip.headers["call-id"]evaluates to the Call-ID of the SIP dialog.
session.connection.protocol.sip.requesturi: Another associative array, this one formed from the URI parameters on the SIP Request-URI of the initial INVITE. The key is the URI parameter name converted to lowercase (again, the case conversion doesn't apply to the parameter value). The value comes from evaluating the URI parameter value as a "JSON value" [RFC4627] for theccxml-paramandaai-paramvalues, and as a string for everything else. The array's toString() function also returns the full SIP Request-URI 🌈 Here's an example. Say the Request-URI is:
sip:dialog@example.com;voicexml=http://example.com;aai=%7b"x":1%2c"y":true%7dThen session.connection.protocol.sip.requesturi["voicexml"] evaluates to "http://example.com", session.connection.protocol.sip.requesturi["aai"].x evaluates to 1 (type Number), session.connection.protocol.sip.requesturi["aai"].y evaluates to true (type Boolean), and session.connection.protocol.sip.requesturi evaluates to the complete Request-URI (type String):
sip:dialog@example.com;voicexml=http://example.com;aai={"x":1,"y":true}session.connection.aai: Evaluates tosession.connection.protocol.sip.requesturi["aai"]🫶session.connection.ccxml: Evaluates tosession.connection.protocol.sip.requesturi["ccxml"]🫶session.connection.protocol.sip.media: This is an array where each element is an object with the following properties 🎧type:: This required property says what kind of media the stream is. The value is a string. It is strongly recommended that you use"audio"for audio media and"video"for video media 🔥direction:: This required property shows which way the media flows, relative tosession.connection.originator. The defined values aresendrecv,sendonly,recvonly, andinactive🦋format:: This property is optional. If it's defined, its value is an array, and each element is an object describing one format of the media (there's an element for each payload type on the m-line). The object has at least one property called"name", whose value is the MIME subtype of the media format (MIME subtypes are registered in [RFC4855]). Other properties can be defined with string values, and they correspond to the required and, if defined, optional parameters of the format 💅
Because of how this is defined, there's one entry in session.connection.protocol.sip.media for each non-disabled m-line in the negotiated media session 🧁 This variable gets updated if the media session characteristics change (for example, because of a re-INVITE). Here's an example: say you have a connection with bidirectional G.711 mu-law "audio" sampled at 8 kHz. Then:
session.connection.protocol.sip.media[0].type -> "audio"
session.connection.protocol.sip.media[0].direction -> "sendrecv"
session.connection.protocol.sip.media[0].format[0].name -> "audio/PCMU"
session.connection.protocol.sip.media[0].format[0].rate -> "8000"Also, when you access SIP headers and Request-URI parameters through the session.connection.protocol.sip.headers and session.connection.protocol.sip.requesturi associative arrays, you can pick either of two semantically equivalent ways to refer to them 🌸 For example, either of these gets a Request-URI parameter named "foo":
session.connection.protocol.sip.requesturi["foo"]
session.connection.protocol.sip.requesturi.foo⚠️ Heads up though: not every SIP header name or Request-URI parameter name is a valid ECMAScript identifier. Those names can only be accessed with the first form (array notation). For example, the Call-ID header can only be accessed as session.connection.protocol.sip.headers["call-id"]. Trying session.connection.protocol.sip.headers.call-id would result in an error 😭
2.5. Terminating a VoiceXML Session ✨
The Application Server can wrap up a VoiceXML Session by sending a BYE to the VoiceXML Media Server. When that BYE shows up for an existing VoiceXML Session, the VoiceXML Media Server MUST send back a 200 OK and MUST throw a connection.disconnect.hangup event to the VoiceXML application. 💅 If the BYE carries a Reason header [RFC3326], its value gets passed along verbatim in the _message variable, which lives inside the catch element's anonymous variable scope. 🎀
The VoiceXML Media Server can also be the one to start ending things by sending its own BYE. This usually happens when the app hits a <disconnect> or <exit>, when the VoiceXML application runs all the way to completion, or when there's an unhandled error somewhere in the app. 😭
For ways to get data back to the Application Server, check out Section 4. 🦋
2.6. Examples 🌸
2.6.1. Basic Session Establishment 🧚
This one shows an Application Server setting up a VoiceXML Session on behalf of a User Agent. It's giving call setup, and it's honestly so pretty to look at. 💖
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|(1) INVITE [offer] | | |
|------------------->|(2) INVITE [offer] | |
|(3) 100 Trying |------------------->| |
|<-------------------|(4) 100 Trying | |
| |<-------------------| |
| | | |
| | |(5) GET |
| | |------------------->|
| | |(6) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(7) 200 OK [answer] | |
|(8) 200 OK [answer] |<-------------------| |
|<-------------------| | |
|(9) ACK | | |
|------------------->|(10) ACK | |
| |------------------->| (execute |
|(11) RTP/SRTP | | VoiceXML |
|.........................................| application) |
| | | |2.6.2. VoiceXML Session Preparation 🍓
Here we're prepping a VoiceXML Session before the outbound call to a User Agent goes out. The session then kicks off as soon as the User Agent picks up. Main character energy. 👑
The [answer1:0] notation means an SDP answer where the media ports are set to 0. 🫶
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
| |(1) INVITE | |
| |-------------------->| |
| |(2) 100 Trying | |
| |<--------------------| |
| | | |
| | |(3) GET |
| | |------------------->|
| | |(4) 200 OK [VXML] |
| | |<-------------------|
| | | |
| |(5) 200 OK [offer1] | |
| |<--------------------| |
| |(6) ACK [answer1:0] | |
|(7) INVITE |-------------------->| |
|<-------------------| | |
|(8) 200 OK [offer2] | | |
|------------------->|(9) INVITE [offer2'] | |
| |-------------------->| |
| |(10) 100 Trying | |
| |<--------------------| |
| |(11) 200 OK [answer2]| |
|(12) ACK [answer2] |<--------------------| |
|<-------------------|(13) ACK | |
| |-------------------->| (execute |
|(14) RTP/SRTP | VoiceXML |
|..........................................| application) |
| | | |Implementation detail: offer2' is derived from offer2. It duplicates the m-lines and a-lines from offer2, but it's a little different because it has to carry the same o-line that was used in answer1:0, just with the version number bumped up. 🔥 Also, if offer1 has more m-lines than offer2, then offer2' needs to be padded with extra (rejected) m-lines. 🙈
2.6.3. MRCP Establishment 🦋
Media Resource Control Protocol (MRCP) [MRCPv2] is a protocol that lets clients, like a VoiceXML Media Server, control media service resources sitting on servers across the network. Things like speech synthesizers, recognizers, verifiers, and identifiers. Iconic. ✨
This example shows how a VoiceXML Media Server can set up an MRCP session in response to an initial INVITE. 🧚
VoiceXML HTTP
User Media MRCPv2 Application
Agent Server Server Server
| | | |
|(1) INVITE [offer1] | | |
|------------------->| | |
|(2) 100 Trying | | |
|<-------------------|(3) GET | |
| |---------------------------------------->|
| | | |
| |(4) 200 OK [VXML] | |
| |<----------------------------------------|
| | | |
| |(5) INVITE [offer2] | |
| |--------------------->| |
| | | |
| |(6) 200 OK [answer2] | |
| |<---------------------| |
| | | |
| |(7) ACK | |
| |--------------------->| |
| | | |
| |(8) MRCP connection | |
| |<-------------------->| |
|(9) 200 OK [answer1]| | |
|<-------------------| | |
| | | |
|(10) ACK | | |
|------------------->| | |
| | | |
|(11) RTP/SRTP | | |
|...........................................| |
| | | |So in this one, the VoiceXML Media Server has to set up a session with the MRCPv2 Media Resource Server before it sends the 200 OK for the initial INVITE. 🫶 It does the offer/answer with the MRCPv2 Media Resource Server based on the SDP capabilities of both the Application Server and the MRCPv2 Media Resource Server. In step (5), it changes the offer it got in step 1 to set up an MRCPv2 session, and it rewrites the SDP so there's an m-line for each MRCPv2 resource being used, plus any other SDP changes MRCPv2 asks for. 💜 Once the offer/answer with the MRCPv2 Media Resource Server is done, the MRCPv2 control channel gets established in step (8). ✨ The MRCPv2 resource gets deallocated when the VoiceXML Media Server sends or receives a BYE (not shown). 💀
3. Media Support 🎀
This section covers the mandatory and optional media support this interface needs. 🌈
3.1. Offer/Answer 💖
The VoiceXML Media Server MUST support the standard offer/answer mechanism of [RFC3264]. 👑 Specifically, if there's no SDP offer in the INVITE, the VoiceXML Media Server will make an offer in the 200 OK response that lists its supported codecs. 🧚
3.2. Early Media 🌸
okay so the VoiceXML Media Server MAY support early establishment of media streams, as described in [RFC3960] ✨. The Application Server can set up media streams between a User Agent and the VoiceXML Media Server at the same time the first VoiceXML document is being processed. That processing might involve generating the page on the fly or chatting with databases and other systems 💅. This is mostly about cutting down the delay before a VoiceXML Session starts, especially when a session with the User Agent already exists and its media stream just needs to be redirected to a VoiceXML Media Server 🦋.
Here's the flow for early media (using the Gateway model from [RFC3960]):
SIP VoiceXML HTTP
User Application Media Application
Agent Server Server Server
| | | |
|..(existing session)..| | |
| |(1) INVITE | |
| |------------------>| |
| | |(2) HTTP GET |
| | |------------------>|
| |(3) 183 [offer] | |
|(4) re-INVITE [offer] |<------------------| |
|<---------------------| | |
|(5) 200 OK [answer] | | |
|--------------------->| | |
|(6) ACK | | |
|<---------------------| | |
| | (7) PRACK [answer]| |
| |------------------>| |
| | (8) PRACK 200 OK | |
| |<------------------| |
|(9) RTP/SRTP | | |
|..........................................| |
| | |(10) 200 OK [VXML] |
| | |<------------------|
| | | |
| |(11) 200 OK | |
| |<------------------| |
| |(12) ACK | |
| |------------------>| (execute |
| | | VoiceXML |
| | | application) |
| | | |Okay, so [RFC3960] actually prefers the Application Server model for early media over the Gateway model 🙄. But the main problem with the Gateway model, forking (where one request gets tried against several targets at once), is way less of a thing when you're sending requests to VoiceXML Media Servers 💖. That's because VoiceXML Media Servers answer every request with a 200 OK when nothing weird is going on, and they usually do it within a few hundred milliseconds ⚡. So they're unlikely targets for forking. Any alternative target would almost never answer faster than an automated system, and if it were automated too, why would you set up a response-time race between two robots? 🤖 Ringing tone generation issues in the Gateway model are also smoothed over, partly because of that quick 200 OK, and partly because this specification mandates that no media packets are generated until an ACK is received, so the User Agent doesn't have to do any media packet analysis 🧠.
Note that a VoiceXML Media Server offering early media does not mean the VoiceXML application can always be fetched and run successfully 😬. For example, if the HTTP Application Server returns a 4xx response in step 10 above, or if the VoiceXML content isn't valid, the VoiceXML Media Server still returns a 500 response (as per Section 2.2). At that point, it's the Application Server's job to tear down any media streams it set up with the media server 🧹.
3.3. Modifying the Media Session 🎀
The VoiceXML Media Server MUST allow the media session to be modified via a re-INVITE, and it SHOULD support the UPDATE method [RFC3311] for the same purpose 💅. Specifically, it MUST be possible to switch streams between sendrecv, sendonly, and recvonly as specified in [RFC3264] ✨.
Unidirectional streams are handy for announcement-only or listening-only (hotword) stuff 📢. The preferred way to put the media session on hold is the one specified in [RFC3264]: the UA changes the stream to sendonly and mutes its own stream 🤫. Modifying the media session doesn't change how the VoiceXML application runs, except that recognition actions started while on hold will end up producing noinput timeouts 😭.
3.4. Audio and Video Codecs 🎶
To get a basic level of interoperability, this section lists a minimal set of codecs and RTP [RFC3550] payload formats that the VoiceXML Media Server MUST support 🔥.
For audio-only applications, G.711 mu-law and A-law MUST be supported, using RTP payload types 0 and 8 [RFC3551]. Other codecs and payload formats MAY be supported too 🌈.
Video telephony applications, which use a video stream alongside the audio stream, are possible in VoiceXML 2.0/2.1 through multimedia file container formats like .3gp [TS26244] and .mp4 [IEC14496-14] 🎬. Video support is optional for this specification. If video is supported, then:
- H.263 Baseline [RFC4629] MUST be supported. For legacy reasons, the 1996 version of H.263 MAY be supported using the RTP payload format defined in [RFC2190] (payload type 34 [RFC3551]) 👵.
- Adaptive Multi-Rate (AMR) narrow band audio [RFC4867] SHOULD be supported 🎤.
- MPEG-4 video [RFC3016] SHOULD be supported 📹.
- MPEG-4 Advanced Audio Coding (AAC) audio [RFC3016] SHOULD be supported 🎧.
- Other codecs and payload formats MAY be supported 🌸.
Video record operations on the VoiceXML Media Server usually need an intra-frame before the recording can start 🎥. The VoiceXML Media Server SHOULD use the mechanism described in [RFC4585] to ask for a new intra-frame to be sent 🙏.
Some applications might transfer confidential information, so the VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711], as discussed in Section 9 🔐.
3.5. DTMF 📞
DTMF events [RFC4733] MUST be supported 💜. When the User Agent doesn't indicate support for [RFC4733], the VoiceXML Media Server MAY detect DTMF using other means, like picking up DTMF tones in the audio stream 👂.
Implementation note: the reason only [RFC4733] telephone-events have to be used when the User Agent says it supports them is to avoid double-detecting DTMF, which could happen if detection on the audio stream ran at the same time 🙃.
4. Returning Data to the Application Server ✨
This section covers the ways data (like a collected utterance or digit info) gets sent from the VoiceXML Media Server back to the Application Server 🚀.
4.1. HTTP Mechanism 🦋
At any point while the VoiceXML application is running, data can be sent back to the Application Server over HTTP using standard VoiceXML elements like <submit> or <subdialog> 💌. The <data> element in VoiceXML 2.1 [VXML21] is the efficient one here 😍. It sends data to the Application Server without a VoiceXML page transition, so it's ideal for short apps like "prompt and collect" 🧚.
For most applications, you need to match the HTTP information up with a specific VoiceXML Session 🧩. One way is to include the SIP Call-ID (available in VoiceXML through the session.connection.protocol.sip.headers array) in the HTTP POST fields 📝. Another option is a unique "POST-back URI", set as an application-specific URI parameter in the Request-URI of the initial INVITE (available in VoiceXML through the session.connection.protocol.sip.requesturi array) 🔗.
Since some applications might transfer confidential information, the VoiceXML Media Server MUST support the https: scheme, as discussed in Section 9 🔒.
4.2. SIP Mechanism ✨
Okay bestie, so data can get sent back to the Application Server through the expr or namelist attribute on <exit>, or through the namelist attribute on <disconnect>. 💖 A VoiceXML Media Server MUST support encoding the expr/namelist data in the message body of a BYE request that it sends because it hit an <exit> or <disconnect> element. 🎀 A VoiceXML Media Server MAY also support putting the expr/namelist data in the message body of the 200 OK that answers a received BYE (so, when the VoiceXML application responds to the connection.disconnect.hangup event and then runs an <exit> with the expr or namelist attribute set). 🦋
Now, sending expr/namelist data in the 200 OK is kind of a big deal 😭. The VoiceXML Media Server has to hold off on the final response to the received BYE until the VoiceXML application's post-disconnect final processing state is done. There's a catch though: this only works if the VoiceXML Media Server responds before the User Agent Client's (UAC's) timer F runs out (it defaults to 32 seconds). ⏳ Also, on unreliable transports, the UAC will resend the BYE following the rules of [RFC3261], so keep that in mind 🙈. The VoiceXML Media Server SHOULD implement the recommendations of [RFC4320] about when to send the 100 Trying provisional response to the BYE request. 💅
If a VoiceXML application runs a <disconnect> [VXML21] and then later runs an <exit> with namelist information, the namelist information from that <exit> element gets thrown away 🗑️. Lowkey harsh, but that's the rule.
Namelist variables first get converted to their "JSON value" equivalent [RFC4627] and then encoded in the message body using the application/x-www-form-urlencoded format content type [HTML4] 🍓. The behavior you get from putting a recording variable in the namelist, or an ECMAScript object with circular references, is not defined, so don't count on anything there 💀. If the expr attribute is used on the <exit> element instead of the namelist attribute, the reserved name __exit is used.
The Application Server needs a way to tell a BYE from a <disconnect> apart from a BYE from an <exit>, so the reserved name __reason is used 🧚. Its value is "disconnect" (without brackets) when it reflects VoiceXML's <disconnect> element, and "exit" (without brackets) when it reflects an explicit <exit> in the VoiceXML document. If the session ends for other reasons (like the media server running into an error), this parameter may be omitted, or it may take on platform-specific values that are prefixed with an underscore 🌈.
This spec extends application/x-www-form-urlencoded by swapping each non-ASCII character for one or more octets of its UTF-8 representation, and then replacing each octet with %HH, where HH is the uppercase hexadecimal notation for the octet value and % is a literal character 🔥. Because of that, the Content-Type header field in a BYE message containing expr/namelist data MUST be set to application/x-www-form-urlencoded;charset=utf-8. No cap, this is the part you can't skip 👑.
Here's a table of <exit> usage examples and what result content you get back ✨:
+----------------------------------------------------------------+
|<exit> Usage | Result Content |
|------------------------------|---------------------------------|
|<exit/> | __reason=exit |
|<exit expr="5"/> | __exit=5&__reason=exit |
|<exit expr="'done'"/> | __exit="done"&__reason=exit |
|<exit expr="userAuthorized"/> | __exit=true&__reason=exit |
|<exit namelist="pin errors"/> | pin=1234&errors=0&__reason=exit |
+----------------------------------------------------------------+
assuming the following VoiceXML variables and values:
userAuthorized = true
pin = 1234
errors = 0For example, take this VoiceXML snippet 🫶:
...
<exit namelist="id pin"/>
...If id equals 1234 and pin equals 9999, say, the BYE message would look something like this 💜:
BYE sip:user@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: sip:dialog@example.com;tag=a6c85cf
To: sip:user@example.com;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Type: application/x-www-form-urlencoded;charset=utf-8
Content-Length: 30
id=1234&pin=9999&__reason=exitSome apps might want to move confidential information around, so the VoiceXML Media Server MUST support the S/MIME encoding of SIP message bodies, as discussed in Section 9 🔒.
5. Outbound Calling 📞
Outbound calls can be kicked off by the Application Server using third-party call control [RFC3725] 🌸.
Flow IV from [RFC3725] is recommended in conjunction with the VoiceXML Session preparation mechanism. This flow has a few perks, namely 💅:
- Selection of a VoiceXML Media Server and preparation of the VoiceXML application can happen before the call is placed, so the callee doesn't sit there waiting ⏰.
- It avoids timing trouble that could pop up with other flows because of the time it takes to fetch and parse the initial VoiceXML document 🙌.
- The flow is IPv6 compatible 🌐.
An example flow for an Application-Server-initiated outbound call is provided in Section 2.6.2 ✨.
6. Call Transfer 🦋
Okay so VoiceXML is at its heart a dialog language, but it also gives you optional call transfer capability 📲. VoiceXML's transfer capability is especially good for the PSTN IVR Service Node use case described in Section 1.1.2 🎀. It is NOT RECOMMENDED to use VoiceXML's call transfer capability in networks that involve Application Servers 🙅♀️. Instead, the Application Server can handle call routing itself by taking signaling actions based on the data sent back to it from the VoiceXML Media Server, either through HTTP or in the SIP BYE message 🧠.
If VoiceXML transfer is supported, the mechanism described in this section MUST be employed 🔥. The transfer flows specified here were picked because they interwork the best across a wide range of SIP devices 🫶. CCXML<->VoiceXML implementations need tight coupling in the form of bidirectional eventing to support all the transfer types defined in VoiceXML, so they may benefit from other approaches, like using SIP event packages [RFC3265] 🧚.
In what follows, the provisional responses have been left out for clarity 🙈.
6.1. Blind 📣
The blind-transfer sequence starts when the VoiceXML Media Server sends a REFER message [RFC3515] on the original SIP dialog ✨. The Refer-To header holds the URI for the called party, as specified through the dest or destexpr attributes on the VoiceXML <transfer> tag 💖.
If the REFER request is accepted, meaning the VoiceXML Media Server gets a 2xx response, the VoiceXML Media Server throws the connection.disconnect.transfer event and terminates the VoiceXML Session with a BYE message 🌈. For blind transfers, implementations MAY use [RFC4488] to suppress the implicit subscription that goes along with the REFER message 🤫.
If the REFER request results in a non-2xx response, the <transfer>'s form item variable (or the event that gets raised) depends on the SIP response, and it's laid out in the table below 📋. Just note that this means the transfer request was rejected 💀.
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.blind |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+Here's an example, with the provisional responses and NOTIFY messages that go with them left out for clarity 🎬:
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................| |
| | |
|(1) REFER | <transfer> |
|<----------------| |
|(2) 202 Accepted | |
|---------------->| |
|(3) BYE | |
|<----------------| |
|(4) 200 OK | |
|---------------->| |
| | Stop RTP (0) |
|(5) INVITE |
|---------------------------------->|
|(6) 200 OK |
|<----------------------------------|
|(7) NOTIFY | |
|---------------->| |
|(8) 200 OK | |
|<--------------- | |
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| | |If the aai or aaiexpr attribute is present on <transfer>, it gets appended to the Refer-To URI as a parameter named "aai" in the REFER method 📎. Reserved characters are URL-encoded as required for SIP/SIPS URIs [RFC3261] 🔤. The mapping of values outside of the ASCII range is platform specific 🌍.
6.2. Bridge 🦋
okay so the bridge transfer makes a little multi-party session with three people in it: the Caller, the VoiceXML Media Server, and the Callee. the Media Server invites the Callee into the session, and it will eject the Callee if the transfer gets terminated. ✨
if the aai or aaiexpr attribute is on <transfer>, it gets tacked onto the Request-URI in the INVITE as a URI parameter named aai. reserved characters get URL-encoded as required for SIP/SIPS URIs [RFC3261], and how values outside the ASCII range are mapped is platform specific. 🌸
while the transfer is trying to connect, the audio from the transferaudio attribute of <transfer> gets streamed to User Agent 1. a VoiceXML Media Server MAY play early media received from the Callee to the Caller if the transferaudio attribute is omitted. 🎀
here's the bridge transfer sequence. the VoiceXML Media Server (acting as a UAC) calls User Agent 2 using the same codecs as User Agent 1. once call setup is done, RTP flows between User Agent 2 and the Media Server, and that stream gets mixed with User Agent 1's. it's giving clean choreography 💅
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0)RTP/SRTP | |
|...................| |
| | |
| <transfer>|(1)INVITE [offer] |
| |------------------>|
| |(2) 200 OK [answer]|
| |<------------------|
| |(3) ACK |
| |------------------>|
| |(4) RTP/SRTP |
| mix |...................|
| (0)+(4)| |if no final response comes back from User Agent 2 to the INVITE and the connecttimeout (an attribute of <transfer>) expires, the VoiceXML Media Server issues a CANCEL to terminate the transaction, and the <transfer>'s form item variable gets set to noanswer. 🙈
if the INVITE gets a non-2xx response, the <transfer>'s form item variable (or the event raised) depends on the SIP response. the table below spells it out 💖
+-------------------------+-----------------------------------+
| SIP Response | <transfer> variable / event |
+-------------------------+-----------------------------------+
| 404 Not Found | error.connection.baddestination |
| 405 Method Not Allowed | error.unsupported.transfer.bridge |
| 408 Request Timeout | noanswer |
| 486 Busy Here | busy |
| 503 Service Unavailable | error.connection.noresource |
| (No response) | network_busy |
| (Other 3xx/4xx/5xx/6xx) | unknown |
+-------------------------+-----------------------------------+once the transfer is established, the VoiceXML Media Server can "listen" to User Agent 1's media stream for speech or DTMF hotwords. when one matches, that triggers a near-end disconnect: the Media Server issues a BYE to User Agent 2, and the VoiceXML application carries on with User Agent 1. a BYE also goes to User Agent 2 if the call runs longer than the maxtime attribute on <transfer>. ⏰
if User Agent 2 sends a BYE during the transfer, the transfer ends and the <transfer>'s form item variable gets the value far_end_disconnect. if User Agent 1 sends a BYE during the transfer, the transfer ends and the VoiceXML event connection.disconnect.transfer gets thrown. 😭
6.3. Consultation 🧚
the consultation transfer (also called attended transfer [RFC5359]) is basically a blind transfer, except the outcome of the transfer call setup is already known, and the Caller doesn't get dropped if the transfer attempt fails. ✨
the consultation transfer starts with the same flow as the bridge transfer, except the RTP streams are not mixed at step (4), and error.unsupported.transfer.consultation replaces error.unsupported.transfer.bridge. once a new SIP dialog with User Agent 2 exists, the rest of the sequence looks like this. provisional responses and the NOTIFY messages that go with them are left out for clarity. consultation transfer uses the Replaces: header [RFC3891], so User Agent 1 calls User Agent 2 and replaces User Agent 2's SIP dialog with the VoiceXML Media Server with a brand new SIP dialog between the Caller and the Callee. it's the ultimate glow-up 🌈
User Agent 1 VoiceXML User Agent 2
(Caller) Media Server (Callee)
| | |
|(0) RTP/SRTP | |
|.................|(4) RTP/SRTP |
| |.................|
|(5) REFER | |
|<----------------| |
|(6) 202 Accepted | |
|---------------->| |
|(7) INVITE Replaces:ms1.example.com|
|---------------------------------->|
|(8) 200 OK |
|<----------------------------------|
|(9) ACK |
|---------------------------------->|
|(10) RTP/SRTP |
|...................................|
| |(11) BYE |
| |<----------------|
| |(12) 200 OK |
| |---------------->| Stop
|(13) NOTIFY | | RTP (4)
|---------------->| |
|(14) 200 OK | |
|<----------------| |
|(15) BYE | |
|<----------------| |
|(16) 200 OK | |
|---------------->| Stop |
| | RTP (0) |if any response other than 202 Accepted comes back for the REFER request sent to User Agent 1, the transfer terminates and an error.unsupported.transfer.consultation event is raised. on top of that, a BYE is sent to User Agent 2 to end the established outbound leg. 🙅♀️
the VoiceXML Media Server knows the consultation transfer worked when it gets a NOTIFY message with a sipfrag of 200 OK. then the connection.disconnect.transfer event is thrown to the VoiceXML application, and a BYE is sent to User Agent 1 to end the session. 🎉 if a NOTIFY comes back with a non-2xx final response in its sipfrag body, the transfer terminates and the associated VoiceXML input item variable is set to 'unknown'.
ngl, here's the important bit: because of how this mechanism works, implementations MUST NOT use [RFC4488] to suppress the implicit subscription associated with the REFER message for consultation transfers. 🚫💀
7. Contributors 🌸
the bulk of the early work on this effort happened over weekly teleconferences and email. the authors especially want to shout out R. J. Auburn (Voxeo), Jeff Haynie (Hakano), and Scott McGlashan (Hewlett-Packard). 🫶
8. Acknowledgements 💜
this document owes its genesis to "A SIP Interface to VoiceXML Dialog Servers," written by J. Rosenberg, P. Mataga, and D. Ladd. the following people also had input into this document:
- R. J. Auburn (Voxeo)
- Hans Bjurstrom (Hewlett-Packard)
- Emily Candell (Comverse)
- Peter Danielsen (Lucent)
- Brian Frasca (Tellme)
- Jeff Haynie (Hakano)
- Scott McGlashan (Hewlett-Packard)
- Matt Oshry (Tellme)
- Rao Surapaneni (Tellme)
the authors also want to acknowledge the support of Cullen Jennings and the Mediactrl chairs, Eric Burger and Spencer Dawkins. 👑
9. Security Considerations 💀
exposing a VoiceXML media service at a well-known address may enhance the possibility of exploitation. for example, an invoked network service may trigger a billing event. 😬 the VoiceXML Media Server is RECOMMENDED to use standard SIP mechanisms [RFC3261] to authenticate requesting endpoints and to authorize them per local policy.
some applications may choose to transfer confidential information to or from the VoiceXML Media Server. to provide data confidentiality, the VoiceXML Media Server MUST implement the sips: and https: schemes in addition to S/MIME message body encoding as described in [RFC3261]. 🔐
the VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] to provide confidentiality, authentication, and replay protection for RTP media streams (including RTCP control traffic). 🛡️
to help mitigate denial-of-service attacks, the VoiceXML Media Server is RECOMMENDED (in addition to authenticating and authorizing endpoints as described above) to provide mechanisms for implementing local policies, such as time-limiting VoiceXML application execution. ⏳
10. IANA Considerations 📋
IANA has registered the following parameters in the SIP/SIPS URI Parameters registry, following the Specification Required policy of [RFC3969]:
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
maxage No RFC 5552
maxstale No RFC 5552
method "get" / "post" RFC 5552
postbody No RFC 5552
ccxml No RFC 5552
aai No RFC 555211. References 📚
11.1. Normative References
Okay bestie, these are the references that the spec depends on to work, so they're the non-negotiable reading list 📚💅
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C Recommendation, Dec 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and
H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual
Streams", RFC 3016, November 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The
Reason Header Field for the Session Initiation
Protocol (SIP)", RFC 3326, December 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP)
Refer Method", RFC 3515, April 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
K. Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party
Call Control (3pcc) in the Session Initiation Protocol
(SIP)", BCP 85, RFC 3725, April 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session
Initiation Protocol (SIP) "Replaces" Header",
RFC 3891, September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information",
RFC 4244, November 2005.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with
the Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, January 2006.
[RFC4488] Levin, O., "Suppression of Session Initiation Protocol
(SIP) REFER Method Implicit Subscription", RFC 4488,
May 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
Rey, "Extended RTP Profile for Real-time Transport
Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
RFC 4585, July 2006.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
July 2006.
[RFC4629] Ott, H., Bormann, C., Sullivan, G., Wenger, S., and R.
Even, "RTP Payload Format for ITU-T Rec", RFC 4629,
January 2007.
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals",
RFC 4733, December 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q.
Xie, "RTP Payload Format and File Storage Format for
the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
Wideband (AMR-WB) Audio Codecs", RFC 4867, April 2007.
[VXML20] McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor,
K., and S. Tryphonas, "Voice Extensible Markup
Language (VoiceXML) Version 2.0", W3C Recommendation,
March 2004.
[VXML21] Oshry, M., Auburn, R J., Baggia, P., Bodell, M.,
Burke, D., Burnett, D., Candell, E., Kilic, H.,
McGlashan, S., Lee, A., Porter, B., and K. Rehor,
"Voice Extensible Markup Language (VoiceXML) Version
2.1", W3C Candidate Recommendation, June 2005.11.2. Informative References
These ones are the lowkey-helpful extras 🌸 Not required to build the thing, but super good to have in your back pocket 🧚
[CCXML10] Auburn, R J., "Voice Browser Call Control: CCXML
Version 1.0", W3C Working Draft, June 2005.
[IEC14496-14] "Information technology. Coding of audio-visual
objects. MP4 file format", ISO/IEC ISO/IEC 14496-
14:2003, October 2003.
[MRCPv2] Shanmugham, S. and D. Burnett, "Media Resource Control
Protocol Version 2 (MRCPv2)", Work in Progress,
November 2008.
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams",
RFC 2190, September 1997.
[RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and
Ringing Tone Generation in the Session Initiation
Protocol (SIP)", RFC 3960, December 2004.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic
Network Media Services with SIP", RFC 4240,
December 2005.
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S.,
and K. Summers, "Session Initiation Protocol Service
Examples", BCP 144, RFC 5359, October 2008.
[TS23002] "3rd Generation Partnership Project: Network
architecture (Release 6)", 3GPP TS 23.002 v6.6.0,
December 2004.
[TS26244] "Transparent end-to-end packet switched streaming
service (PSS); 3GPP file format (3GP)", 3GPP TS 26.244
v6.4.0, December 2004.Appendix A. Notes on Normative References 🎀
Okay so here's the tea: we make a "downref" normative reference to [RFC4627]. That one's an Informational document describing a proprietary (but extremely popular) format, so it gets its own little spotlight here 💜✨
Authors' Addresses 🦋
Meet the girlies who wrote this whole thing 🫶
Dave Burke
Google
Belgrave House, 76 Buckingham Palace Road
London SW1W 9TQ
United Kingdom
EMail: daveburke@google.com
Mark Scott
Genesys
1120 Finch Avenue West, 8th floor
Toronto, Ontario M3J 3H7
Canada
EMail: Mark.Scott@genesyslab.com📦 where this page comes from
- ietf: rfc5552 2009-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms