< draft-ietf-mediactrl-vxml-03.txt   draft-ietf-mediactrl-vxml-04.txt >
Mediactrl D. Burke Mediactrl D. Burke
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Scott Intended status: Standards Track M. Scott
Expires: July 13, 2009 Genesys Expires: August 12, 2009 Genesys
Jan 9, 2009 Feb 8, 2009
SIP Interface to VoiceXML Media Services SIP Interface to VoiceXML Media Services
draft-ietf-mediactrl-vxml-03.txt draft-ietf-mediactrl-vxml-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 13, 2009. This Internet-Draft will expire on August 12, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 17 skipping to change at page 4, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1. IVR Services with Application Servers . . . . . . . . 5 1.1.1. IVR Services with Application Servers . . . . . . . . 5
1.1.2. PSTN IVR Service Node . . . . . . . . . . . . . . . . 6 1.1.2. PSTN IVR Service Node . . . . . . . . . . . . . . . . 6
1.1.3. 3GPP IMS Media Resource Function (MRF) . . . . . . . . 7 1.1.3. 3GPP IMS Media Resource Function (MRF) . . . . . . . . 7
1.1.4. CCXML <-> VoiceXML Interaction . . . . . . . . . . . . 8 1.1.4. CCXML <-> VoiceXML Interaction . . . . . . . . . . . . 8
1.1.5. Other Use Cases . . . . . . . . . . . . . . . . . . . 8 1.1.5. Other Use Cases . . . . . . . . . . . . . . . . . . . 8
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. VoiceXML Session Establishment and Termination . . . . . . . . 10 2. VoiceXML Session Establishment and Termination . . . . . . . . 10
2.1. Service Identification . . . . . . . . . . . . . . . . . . 10 2.1. Service Identification . . . . . . . . . . . . . . . . . . 10
2.2. Initiating a VoiceXML Session . . . . . . . . . . . . . . 12 2.2. Initiating a VoiceXML Session . . . . . . . . . . . . . . 13
2.3. Preparing a VoiceXML Session . . . . . . . . . . . . . . . 14 2.3. Preparing a VoiceXML Session . . . . . . . . . . . . . . . 14
2.4. Session Variable Mappings . . . . . . . . . . . . . . . . 14 2.4. Session Variable Mappings . . . . . . . . . . . . . . . . 15
2.5. Terminating a VoiceXML Session . . . . . . . . . . . . . . 17 2.5. Terminating a VoiceXML Session . . . . . . . . . . . . . . 18
2.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.1. Basic Session Establishment . . . . . . . . . . . . . 18 2.6.1. Basic Session Establishment . . . . . . . . . . . . . 18
2.6.2. VoiceXML Session Preparation . . . . . . . . . . . . . 18 2.6.2. VoiceXML Session Preparation . . . . . . . . . . . . . 19
2.6.3. MRCP Establishment . . . . . . . . . . . . . . . . . . 19 2.6.3. MRCP Establishment . . . . . . . . . . . . . . . . . . 20
3. Media Support . . . . . . . . . . . . . . . . . . . . . . . . 22 3. Media Support . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . 22 3.1. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 22 3.2. Early Media . . . . . . . . . . . . . . . . . . . . . . . 23
3.3. Modifying the Media Session . . . . . . . . . . . . . . . 24 3.3. Modifying the Media Session . . . . . . . . . . . . . . . 25
3.4. Audio and Video Codecs . . . . . . . . . . . . . . . . . . 24 3.4. Audio and Video Codecs . . . . . . . . . . . . . . . . . . 25
3.5. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.5. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Returning Data to the Application Server . . . . . . . . . . . 26 4. Returning Data to the Application Server . . . . . . . . . . . 27
4.1. HTTP Mechanism . . . . . . . . . . . . . . . . . . . . . . 26 4.1. HTTP Mechanism . . . . . . . . . . . . . . . . . . . . . . 27
4.2. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 26 4.2. SIP Mechanism . . . . . . . . . . . . . . . . . . . . . . 27
5. Outbound Calling . . . . . . . . . . . . . . . . . . . . . . . 29 5. Outbound Calling . . . . . . . . . . . . . . . . . . . . . . . 30
6. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. Blind . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Blind . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2. Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3. Consultation . . . . . . . . . . . . . . . . . . . . . . . 33 6.3. Consultation . . . . . . . . . . . . . . . . . . . . . . . 34
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. Changes since last version: . . . . . . . . . . . . . . . . . 40 11. Changes since last version: . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42
12.2. Informative References . . . . . . . . . . . . . . . . . . 43 12.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Notes on Normative References . . . . . . . . . . . . 45 Appendix A. Notes on Normative References . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
VoiceXML [VXML20], [VXML21] is a World Wide Web Consortium (W3C) VoiceXML [VXML20], [VXML21] is a World Wide Web Consortium (W3C)
standard for creating audio and video dialogs that feature standard for creating audio and video dialogs that feature
synthesized speech, digitized audio, recognition of spoken and DTMF synthesized speech, digitized audio, recognition of spoken and DTMF
key input, recording of audio and video, telephony, and mixed key input, recording of audio and video, telephony, and mixed
initiative conversations. VoiceXML allows Web-based development and initiative conversations. VoiceXML allows Web-based development and
content delivery paradigms to be used with interactive video and content delivery paradigms to be used with interactive video and
voice response applications. voice response applications.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
improves interoperability between application servers and media improves interoperability between application servers and media
servers, and reduces the provisioning overhead that would be required servers, and reduces the provisioning overhead that would be required
if use of a media server by an application server required an if use of a media server by an application server required an
individually provisioned URI. In this respect, this document (and individually provisioned URI. In this respect, this document (and
[RFC4240]) do not add semantics to the user part, but rather [RFC4240]) do not add semantics to the user part, but rather
standardize the way that targets on media servers are provisioned. standardize the way that targets on media servers are provisioned.
Further, since application servers - and not human beings - are Further, since application servers - and not human beings - are
generally the clients of media servers, issues such as interpretation generally the clients of media servers, issues such as interpretation
and internationalization do not apply. and internationalization do not apply.
Exposing a VoiceXML media service with a well-known address may
enhance the possibility of exploitation: 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" The initial VoiceXML document is specified with the "voicexml"
parameter. In addition, parameters are defined that control how the parameter. In addition, parameters are defined that control how the
VoiceXML Media Server fetches the specified VoiceXML document. The VoiceXML Media Server fetches the specified VoiceXML document. The
list of parameters defined by this specification is as follows (note list of parameters defined by this specification is as follows (note
the parameter names are case-insensitive): the parameter names are case-insensitive):
voicexml: URI of the initial VoiceXML document to fetch. This will voicexml: URI of the initial VoiceXML document to fetch. This will
typically contain an HTTP URI, but may use other URI schemes, for typically contain an HTTP URI, but may use other URI schemes, for
example to refer to local, static VoiceXML documents. If the example to refer to local, static VoiceXML documents. If the
"voicexml" parameter is omitted, the VoiceXML Media Server may "voicexml" parameter is omitted, the VoiceXML Media Server may
skipping to change at page 12, line 20 skipping to change at page 12, line 41
Special characters contained in the dialog-param, postbody-param, Special characters contained in the dialog-param, postbody-param,
ccxml-param, and aai-param values must be URL-encoded ("escaped") as ccxml-param, and aai-param values must be URL-encoded ("escaped") as
required by the SIP URI syntax, for example '?' (%3f), '=' (%3d), and required by the SIP URI syntax, for example '?' (%3f), '=' (%3d), and
';' (%3b). The VoiceXML Media Server MUST therefore unescape these ';' (%3b). The VoiceXML Media Server MUST therefore unescape these
parameter values before making use of them or exposing them to parameter values before making use of them or exposing them to
running VoiceXML applications. It is important that the VoiceXML running VoiceXML applications. It is important that the VoiceXML
Media Server only unescape the parameter values once since the Media Server only unescape the parameter values once since the
desired VoiceXML URI value could itself be URL encoded, for example. desired VoiceXML URI value could itself be URL encoded, for example.
Since some applications may choose to transfer confidential
information, the VoiceXML Media Server MUST support the sip: scheme
as discussed in Section 9.
Informative note: With respect to the postbody-param value, since the Informative note: With respect to the postbody-param value, since the
application/x-www-form-urlencoded content itself escapes non- application/x-www-form-urlencoded content itself escapes non-
alphanumeric characters by inserting %HH replacements, the escaping alphanumeric characters by inserting %HH replacements, the escaping
rules above will result in the '%' characters being further escaped rules above will result in the '%' characters being further escaped
in addition to the '&' and '=' name/value separators. in addition to the '&' and '=' name/value separators.
As an example, the following SIP Request-URI identifies the use of As an example, the following SIP Request-URI identifies the use of
VoiceXML media services, with VoiceXML media services, with
'http://appserver.example.com/promptcollect.vxml' as the initial 'http://appserver.example.com/promptcollect.vxml' as the initial
VoiceXML document, to be fetched with max-age/max-stale values of VoiceXML document, to be fetched with max-age/max-stale values of
skipping to change at page 17, line 43 skipping to change at page 18, line 18
BYE to the VoiceXML Media Server. Upon receipt of a BYE in the BYE to the VoiceXML Media Server. Upon receipt of a BYE in the
context of an existing VoiceXML Session, the VoiceXML Media Server context of an existing VoiceXML Session, the VoiceXML Media Server
MUST send a 200 OK response, and MUST throw a MUST send a 200 OK response, and MUST throw a
'connection.disconnect.hangup' event to the VoiceXML application. If 'connection.disconnect.hangup' event to the VoiceXML application. If
the Reason header [RFC3326] is present on the BYE Request, then the the Reason header [RFC3326] is present on the BYE Request, then the
value of the Reason header is provided verbatim via the '_message' value of the Reason header is provided verbatim via the '_message'
variable within the catch element's anonymous variable scope. variable within the catch element's anonymous variable scope.
The VoiceXML Media Server may also initiate termination of the The VoiceXML Media Server may also initiate termination of the
session by issuing a BYE request. This will typically occur as a session by issuing a BYE request. This will typically occur as a
result of encoutering a <disconnect> or <exit> in the VoiceXML result of encountering a <disconnect> or <exit> in the VoiceXML
application, due to the VoiceXML application running to completion, application, due to the VoiceXML application running to completion,
or due to unhandled errors within the VoiceXML application. or due to unhandled errors within the VoiceXML application.
See Section 4 for mechanisms to return data to the Application See Section 4 for mechanisms to return data to the Application
Server. Server.
2.6. Examples 2.6. Examples
2.6.1. Basic Session Establishment 2.6.1. Basic Session Establishment
skipping to change at page 25, line 18 skipping to change at page 26, line 18
4. MPEG-4 AAC audio [RFC3016] SHOULD be supported. 4. MPEG-4 AAC audio [RFC3016] SHOULD be supported.
5. Other codecs and payload formats MAY be supported. 5. Other codecs and payload formats MAY be supported.
Video record operations carried out by the VoiceXML Media Server Video record operations carried out by the VoiceXML Media Server
typically require receipt of an intra-frame before the recording can typically require receipt of an intra-frame before the recording can
commence. The VoiceXML Media Server SHOULD use the mechanism commence. The VoiceXML Media Server SHOULD use the mechanism
described in [RFC4585] to request that a new intra-frame be sent. described in [RFC4585] to request that a new intra-frame be sent.
Since some applications may choose to transfer confidential
information, the VoiceXML Media Server MUST support Secure RTP (SRTP)
[RFC3711] as discussed in Section 9.
3.5. DTMF 3.5. DTMF
DTMF events [RFC4733] MUST be supported. When the user agent does DTMF events [RFC4733] MUST be supported. When the user agent does
not indicate support for [RFC4733] the VoiceXML Media Server MAY not indicate support for [RFC4733] the VoiceXML Media Server MAY
perform DTMF detection using other means such as detecting DTMF tones perform DTMF detection using other means such as detecting DTMF tones
in the audio stream. Implementation note: the reason why only in the audio stream. Implementation note: the reason why only
[RFC4733] telephone-events must be used when the user agent indicates [RFC4733] telephone-events must be used when the user agent indicates
support of it is to avoid the risk of double detection of DTMF if support of it is to avoid the risk of double detection of DTMF if
detection on the audio stream was simultaneously applied. detection on the audio stream was simultaneously applied.
skipping to change at page 26, line 30 skipping to change at page 27, line 30
For most applications, it is necessary to correlate the information For most applications, it is necessary to correlate the information
being passed over HTTP with a particular VoiceXML Session. One way being passed over HTTP with a particular VoiceXML Session. One way
this can be achieved is to include the SIP Call-ID (accessible in this can be achieved is to include the SIP Call-ID (accessible in
VoiceXML via the session.connection.protocol.sip.headers array) VoiceXML via the session.connection.protocol.sip.headers array)
within the HTTP POST fields. Alternatively, a unique "POST-back URI" within the HTTP POST fields. Alternatively, a unique "POST-back URI"
can be specified as an application-specific URI parameter in the can be specified as an application-specific URI parameter in the
Request-URI of the initial INVITE (accessible in VoiceXML via the Request-URI of the initial INVITE (accessible in VoiceXML via the
session.connection.protocol.sip.requesturi array). session.connection.protocol.sip.requesturi array).
Since some applications may choose to transfer confidential
information, the VoiceXML Media Server MUST support the https: scheme
as discussed in Section 9.
4.2. SIP Mechanism 4.2. SIP Mechanism
Data can be returned to the Application Server via the expr or Data can be returned to the Application Server via the expr or
namelist attribute on <exit> or the namelist attribute on namelist attribute on <exit> or the namelist attribute on
<disconnect>. A VoiceXML Media Server MUST support encoding of the <disconnect>. A VoiceXML Media Server MUST support encoding of the
expr / namelist data in the message body of a BYE request sent from expr / namelist data in the message body of a BYE request sent from
the VoiceXML Media Server as a result of encountering the <exit> or the VoiceXML Media Server as a result of encountering the <exit> or
<disconnect> element. A VoiceXML Media Server MAY support inclusion <disconnect> element. A VoiceXML Media Server MAY support inclusion
of the expr / namelist data in the message body of the 200 OK message of the expr / namelist data in the message body of the 200 OK message
in response to a received BYE request (i.e. when the VoiceXML in response to a received BYE request (i.e. when the VoiceXML
skipping to change at page 27, line 10 skipping to change at page 28, line 14
UAC's timer F expires (defaults to 32 seconds). Moreover, for UAC's timer F expires (defaults to 32 seconds). Moreover, for
unreliable transports, the UAC will retransmit the BYE request unreliable transports, the UAC will retransmit the BYE request
according to the rules of [RFC3261]. The VoiceXML Media Server according to the rules of [RFC3261]. The VoiceXML Media Server
SHOULD implement the recommendations of [RFC4320] regarding when to SHOULD implement the recommendations of [RFC4320] regarding when to
send the 100 Trying provisional response to the BYE request. send the 100 Trying provisional response to the BYE request.
If a VoiceXML Application executes a <disconnect> [VXML21] and then If a VoiceXML Application executes a <disconnect> [VXML21] and then
subsequently executes an <exit> with namelist information, the subsequently executes an <exit> with namelist information, the
namelist information from the <exit> element is discarded. namelist information from the <exit> element is discarded.
Namelist variables are first converted to to their JSON value Namelist variables are first converted to their JSON value equivalent
equivalent [RFC4627] and encoded in the message body using the [RFC4627] and encoded in the message body using the application/
application/x-www-form-urlencoded format content type [HTML4]. The x-www-form-urlencoded format content type [HTML4]. The behavior
behavior resulting from specifying a recording variable in the resulting from specifying a recording variable in the namelist or an
namelist or an ECMAScript object with circular references is not ECMAScript object with circular references is not defined. If the
defined. If the expr attribute is specified on the <exit> element expr attribute is specified on the <exit> element instead of the
instead of the namelist attribute, the reserved name __exit is used. namelist attribute, the reserved name __exit is used.
To allow the application server to differentiate between a BYE To allow the application server to differentiate between a BYE
resulting from a <disconnect> from one resulting from an <exit>, the resulting from a <disconnect> from one resulting from an <exit>, the
reserved name __reason is used, with a value of "disconnect" (without reserved name __reason is used, with a value of "disconnect" (without
brackets) to reflect the use of VoiceXML's <disconnect> element, and brackets) to reflect the use of VoiceXML's <disconnect> element, and
a value of "exit" (without brackets) to an explicit <exit> in the a value of "exit" (without brackets) to an explicit <exit> in the
VoiceXML document. If the session terminates for other reasons (such VoiceXML document. If the session terminates for other reasons (such
as the media server encountering an error), this parameter may be as the media server encountering an error), this parameter may be
omitted, or may take on platform-specific values prefixed with an omitted, or may take on platform-specific values prefixed with an
underscore. underscore.
skipping to change at page 29, line 5 skipping to change at page 29, line 40
Max-Forwards: 70 Max-Forwards: 70
From: sip:dialog@example.com;tag=a6c85cf From: sip:dialog@example.com;tag=a6c85cf
To: sip:user@example.com;tag=1928301774 To: sip:user@example.com;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 231 BYE CSeq: 231 BYE
Content-Type: application/x-www-form-urlencoded;charset=utf-8 Content-Type: application/x-www-form-urlencoded;charset=utf-8
Content-Length: 30 Content-Length: 30
id=1234&pin=9999&__reason=exit id=1234&pin=9999&__reason=exit
Since some applications may choose to transfer confidential
information, the VoiceXML Media Server MUST support the S/MIME
encoding of SIP message bodies as discussed in Section 9.
5. Outbound Calling 5. Outbound Calling
Outbound calls can be triggered via the Application Server using Outbound calls can be triggered via the Application Server using
third party call control [RFC3725]. third party call control [RFC3725].
Flow IV from [RFC3725] is recommended in conjunction with the Flow IV from [RFC3725] is recommended in conjunction with the
VoiceXML Session preparation mechanism. This flow has several VoiceXML Session preparation mechanism. This flow has several
advantages over others, namely: advantages over others, namely:
1. Selection of a VoiceXML Media Server and preparation of the 1. Selection of a VoiceXML Media Server and preparation of the
skipping to change at page 38, line 7 skipping to change at page 39, line 7
Matt Oshry (Tellme) Matt Oshry (Tellme)
Rao Surapaneni (Tellme) Rao Surapaneni (Tellme)
The authors would like to acknowledge the support of Cullen Jennings The authors would like to acknowledge the support of Cullen Jennings
and the Mediactrl chairs, Eric Burger and Spencer Dawkins. and the Mediactrl chairs, Eric Burger and Spencer Dawkins.
9. Security Considerations 9. Security Considerations
Exposing network services with well-known addresses may enhance the Exposing a VoiceXML media service with a well-known address may
possibility of exploitation. The VoiceXML Media Server MUST support enhance the possibility of exploitation (for example an invoked
digest authentication of requesting endpoints. network service may trigger a billing event). The VoiceXML Media
Server is RECOMMENDED to use standard SIP mechanisms [RFC3261] to
The transfer mechanism described in section 6 makes it possible for authenticate requesting endpoints and authorize per local policy.
application developers to initiate outbound calls that consume
network resources, have billing implications, and may create
untraceable calls. The VoiceXML Media Server is RECOMMENDED to
provide local policies for authorizing and limiting call placement in
addition to providing call detail recording for the purposes of
generating audit trails and billing.
Some applications may choose to transfer confidential information to Some applications may choose to transfer confidential information to
or from the VoiceXML Media Server. The VoiceXML Media Server MUST or from the VoiceXML Media Server. To provide data confidentiality,
implement the sips: and https: schemes to provide data the VoiceXML Media Server MUST implement the sips: and https: schemes
confidentiality. in addition to S/MIME message body encoding as described in
[RFC3261].
The VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] to The VoiceXML Media Server MUST support Secure RTP (SRTP) [RFC3711] to
provide confidentiality, authentication, and replay protection for provide confidentiality, authentication, and replay protection for
RTP media streams (including RTCP control traffic). RTP media streams (including RTCP control traffic).
To mitigate against the possibility for denial of service attacks, To mitigate against the possibility for denial of service attacks,
the VoiceXML Media Server is RECOMMENDED to have local policies such the VoiceXML Media Server is RECOMMENDED (in addition to
as time-limiting VoiceXML application execution. authenticating and authorizing endpoints described above) to provide
mechanisms for implementing local policies such as time-limiting of
VoiceXML application execution.
10. IANA Considerations 10. IANA Considerations
IANA SHALL register the following parameters in the SIP/SIPS URI IANA SHALL register the following parameters in the SIP/SIPS URI
Parameters registry, following the specification required policy of Parameters registry, following the specification required policy of
RFC 3969: RFC 3969:
Parameter Name Predefined Values Reference Parameter Name Predefined Values Reference
-------------- ----------------- --------- -------------- ----------------- ---------
maxage no TBD maxage no TBD
maxstale no TBD maxstale no TBD
method "get" / "post" TBD method "get" / "post" TBD
postbody no TBD postbody no TBD
ccxml no TBD
aai no TBD
11. Changes since last version: 11. Changes since last version:
o Added rationale for standardizing the SIP URI user part to o Tightened up Security Considerations per comments from IESG review
'dialog'
o Specified that the Request-URI parameter names are case- o Added missing ccxml and aai IANA registrations
insensitive and the corresponding array keys are converted to
lower-case o Miscellaneous typos
12. References 12. References
12.1. Normative References 12.1. Normative References
[HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML4] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C Recommendation, Dec 1999. Specification", W3C Recommendation, Dec 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 19 change blocks. 
62 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/