draft-ietf-sipcore-info-events-09.txt   draft-ietf-sipcore-info-events-10.txt 
SIPCORE C. Holmberg SIPCORE C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 2976 (if approved) E. Burger Obsoletes: 2976 (if approved) E. Burger
Intended status: Standards Track NeuStar, Inc. Intended status: Standards Track NeuStar, Inc.
Expires: April 1, 2011 H. Kaplan Expires: April 15, 2011 H. Kaplan
Acme Packet Acme Packet
September 28, 2010 October 12, 2010
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-09 draft-ietf-sipcore-info-events-10
Abstract Abstract
This document defines a method, INFO, for the Session Initiation This document defines a method, INFO, for the Session Initiation
Protocol (SIP), and an Info Package mechanism. The document Protocol (SIP), and an Info Package mechanism. The document
obsoletes RFC 2976. For backward compatibility the document also obsoletes RFC 2976. For backward compatibility the document also
specifies a "legacy" mode of usage of the INFO method that is specifies a "legacy" mode of usage of the INFO method that is
compatible with the usage previously defined in RFC 2976, referred to compatible with the usage previously defined in RFC 2976, referred to
as "legacy INFO Usage" in this document. as "legacy INFO Usage" in this document.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 1, 2011. This Internet-Draft will expire on April 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 2, line 47 skipping to change at page 2, line 47
5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12
6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13
6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13
7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Info-Package header field . . . . . . . . . . . . . . . . 15 7.2. Info-Package header field . . . . . . . . . . . . . . . . 15
7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16 7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16
8. Info Package Considerations . . . . . . . . . . . . . . . . . 16 8. Info Package Considerations . . . . . . . . . . . . . . . . . 16
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16 8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16
8.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 8.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 16
8.3.1. Alternative SIP signaling plane mechanisms . . . . . . 16 8.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 17
8.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18 8.4.1. Alternative SIP signaling plane mechanisms . . . . . . 17
8.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19 8.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18
8.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19
9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21
10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 6, line 24 skipping to change at page 6, line 24
2976, referred to as "legacy INFO Usage". 2976, referred to as "legacy INFO Usage".
For backward compatibility purposes, this document does not deprecate For backward compatibility purposes, this document does not deprecate
legacy INFO usages, and does not mandate users to define Info legacy INFO usages, and does not mandate users to define Info
Packages for such usages. However: Packages for such usages. However:
1. A UA MUST NOT insert an Info-Package header field in a legacy 1. A UA MUST NOT insert an Info-Package header field in a legacy
INFO request (as described in Section 3, an INFO request INFO request (as described in Section 3, an INFO request
associated with an Info Package always contains an Info-Package associated with an Info Package always contains an Info-Package
header field). header field).
2. It is strongly RECOMMENDED that any new usage uses the Info 2. Any new usage MUST use the Info Package mechanism defined in this
Package mechanism defined in this specification, since it does specification, since it does not share the issues associated with
not share the issues associated with legacy INFO usage, and since legacy INFO usage, and since Info Packages can be registered with
Info Packages can be registered with IANA. IANA.
3. UAs are allowed to enable both legacy INFO usages and Info 3. UAs are allowed to enable both legacy INFO usages and Info
Package usages as part of the same invite dialog usage, but UAs Package usages as part of the same invite dialog usage, but UAs
SHALL NOT mix legacy INFO usages and Info Package usages in order SHALL NOT mix legacy INFO usages and Info Package usages in order
to transport the same application level information. If to transport the same application level information. If
possible, UAs SHALL prefer the usage of an Info Package. possible, UAs SHALL prefer the usage of an Info Package.
4. The INFO Method 4. The INFO Method
4.1. General 4.1. General
skipping to change at page 16, line 34 skipping to change at page 16, line 34
8.2. Appropriateness of Info Package Usage 8.2. Appropriateness of Info Package Usage
When designing an Info Package, for application level information When designing an Info Package, for application level information
exchange, it is important to consider: is signaling, using INFO exchange, it is important to consider: is signaling, using INFO
requests, within a SIP dialog, an appropriate mechanism for the use- requests, within a SIP dialog, an appropriate mechanism for the use-
case? Is it because it is the most reasonable and appropriate case? Is it because it is the most reasonable and appropriate
choice, or merely because "it's easy"? Choosing an inappropriate choice, or merely because "it's easy"? Choosing an inappropriate
mechanism for a specific use-case can cause negative effects in SIP mechanism for a specific use-case can cause negative effects in SIP
networks where the mechanism is used. networks where the mechanism is used.
8.3. Alternative Mechanisms 8.3. INFO Request Rate and Volume
8.3.1. Alternative SIP signaling plane mechanisms
8.3.1.1. General
This subsection describes some alternative mechanisms for
transporting application information on the SIP signaling plane,
using SIP messages.
8.3.1.2. INFO Request Rate and Volume
INFO messages differ from many other sorts of SIP messages in that INFO messages differ from many other sorts of SIP messages in that
they carry application information, and the size and rate of the INFO they carry application information, and the size and rate of the INFO
message is directly determined by the application. This can cause message is directly determined by the application. This can cause
application information traffic to interfere with other traffic on application information traffic to interfere with other traffic on
that infrastructure, or to self-interfere when data rates become too that infrastructure, or to self-interfere when data rates become too
high. high.
There is no default throttling mechanism for INFO requests. Apart There is no default throttling mechanism for INFO requests. Apart
from the SIP session establishment, the number of SIP messages from the SIP session establishment, the number of SIP messages
skipping to change at page 17, line 37 skipping to change at page 17, line 27
exchange of bulk data beyond these limits, especially if the headers exchange of bulk data beyond these limits, especially if the headers
plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768].
Appropriate mechanisms for such traffic include the Hypertext Appropriate mechanisms for such traffic include the Hypertext
Transfer Protocol (HTTP) [RFC2616], the Message Session Relay Transfer Protocol (HTTP) [RFC2616], the Message Session Relay
Protocol (MSRP) [RFC4975], or other media plane data transport Protocol (MSRP) [RFC4975], or other media plane data transport
mechanisms. mechanisms.
RFC 5405 [RFC5405] provides additional guidelines for applications RFC 5405 [RFC5405] provides additional guidelines for applications
using UDP that may be useful background reading. using UDP that may be useful background reading.
8.3.1.3. SUBSCRIBE/NOTIFY 8.4. Alternative Mechanisms
8.4.1. Alternative SIP signaling plane mechanisms
8.4.1.1. General
This subsection describes some alternative mechanisms for
transporting application information on the SIP signaling plane,
using SIP messages.
8.4.1.2. SUBSCRIBE/NOTIFY
An alternative for application level interaction is to use An alternative for application level interaction is to use
subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and
NOTIFY methods. Using that mechanism, a UA requests state NOTIFY methods. Using that mechanism, a UA requests state
information, such as key pad presses from a device to an application information, such as key pad presses from a device to an application
server or key map images from an application server to a device. server or key map images from an application server to a device.
Event Packages [RFC3265] perform the role of disambiguating the Event Packages [RFC3265] perform the role of disambiguating the
context of a message for subscription-based events. The Info Package context of a message for subscription-based events. The Info Package
mechanism provides similar functionality for application information mechanism provides similar functionality for application information
skipping to change at page 18, line 23 skipping to change at page 18, line 23
and B2BUAs, the resource impact caused by the subscription dialogs and B2BUAs, the resource impact caused by the subscription dialogs
needs to be considered. The number of subscription dialogs per user needs to be considered. The number of subscription dialogs per user
also needs to be considered. also needs to be considered.
As for any other SIP signaling plane based mechanism for transporting As for any other SIP signaling plane based mechanism for transporting
application information, the SUBSCRIBE/NOTIFY messages can put a application information, the SUBSCRIBE/NOTIFY messages can put a
significant burden on intermediate SIP entities which are part of the significant burden on intermediate SIP entities which are part of the
dialog route set, but do not have any interest in the application dialog route set, but do not have any interest in the application
information transported between the end users. information transported between the end users.
8.3.1.4. MESSAGE 8.4.1.3. MESSAGE
The MESSAGE method [RFC3428] defines one-time instant message The MESSAGE method [RFC3428] defines one-time instant message
exchange, typically for sending MIME contents for rendering to the exchange, typically for sending MIME contents for rendering to the
user. user.
8.3.2. Media Plane Mechanisms 8.4.2. Media Plane Mechanisms
8.3.2.1. General 8.4.2.1. General
In SIP, media plane channels associated with SIP dialogs are In SIP, media plane channels associated with SIP dialogs are
established using SIP signaling, but the data exchanged on the media established using SIP signaling, but the data exchanged on the media
plane channel does not traverse SIP signaling intermediates, so if plane channel does not traverse SIP signaling intermediates, so if
there will be a lot of information exchanged, and there is no need there will be a lot of information exchanged, and there is no need
for the SIP signaling intermediaries to examine the information, it for the SIP signaling intermediaries to examine the information, it
is recommended to use a media plane mechanism, rather than a SIP is recommended to use a media plane mechanism, rather than a SIP
signaling based. signaling based.
A low latency requirement for the exchange of information is one A low latency requirement for the exchange of information is one
strong indicator for using a media channel. Exchanging information strong indicator for using a media channel. Exchanging information
through the SIP routing network can introduce hundreds of through the SIP routing network can introduce hundreds of
milliseconds of latency. milliseconds of latency.
8.3.2.2. MRCP 8.4.2.2. MRCP
One mechanism for media plane exchange of application data is the One mechanism for media plane exchange of application data is the
Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2], Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2],
where a media plane connection-oriented channel, such as a where a media plane connection-oriented channel, such as a
Transmission Control Protocol (TCP) [RFC0793] or Stream Control Transmission Control Protocol (TCP) [RFC0793] or Stream Control
Transmission Protocol (SCTP) [RFC4960] stream is established. Transmission Protocol (SCTP) [RFC4960] stream is established.
8.3.2.3. MRSP 8.4.2.3. MRSP
MSRP [RFC4975] defines session-based instant messaging as well as MSRP [RFC4975] defines session-based instant messaging as well as
bulk file transfer and other such large-volume uses. bulk file transfer and other such large-volume uses.
8.3.3. Non-SIP related mechanisms 8.4.3. Non-SIP related mechanisms
Another alternative is to use a SIP-independent mechanism, such as Another alternative is to use a SIP-independent mechanism, such as
HTTP [RFC2616]. In this model, the UA knows about a rendezvous point HTTP [RFC2616]. In this model, the UA knows about a rendezvous point
to direct HTTP requests to for the transfer of information. Examples to direct HTTP requests to for the transfer of information. Examples
include encoding of a prompt to retrieve in the SIP Request URI in include encoding of a prompt to retrieve in the SIP Request URI in
[RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-
voicexml21-20070619] script. voicexml21-20070619] script.
9. Syntax 9. Syntax
skipping to change at page 20, line 21 skipping to change at page 20, line 21
Info Package specifications MUST NOT weaken any behavior designated Info Package specifications MUST NOT weaken any behavior designated
with "SHOULD" or "MUST" in this specification. However, Info with "SHOULD" or "MUST" in this specification. However, Info
Packages specifications MAY strengthen "SHOULD", "MAY", or Packages specifications MAY strengthen "SHOULD", "MAY", or
"RECOMMENDED" requirements to "MUST" strength if applications "RECOMMENDED" requirements to "MUST" strength if applications
associated with the Info Package require it. associated with the Info Package require it.
Info Package specifications MUST address the issues defined in the Info Package specifications MUST address the issues defined in the
following subsections, or document why an issue is not applicable for following subsections, or document why an issue is not applicable for
the specific Info Package. the specific Info Package.
Section 8.3 describes alternative mechanisms, which should be Section 8.4 describes alternative mechanisms, which should be
considered as part of the process for solving a specific use-case, considered as part of the process for solving a specific use-case,
when there is a need for transporting application information. when there is a need for transporting application information.
10.2. Overall Description 10.2. Overall Description
The Info Package specification MUST contain an overall description of The Info Package specification MUST contain an overall description of
the Info Package: what type of information are carried in INFO the Info Package: what type of information are carried in INFO
requests associated with the Info Package, and for what type of requests associated with the Info Package, and for what type of
applications and functionalities UAs can use the Info Package. applications and functionalities UAs can use the Info Package.
skipping to change at page 34, line 21 skipping to change at page 34, line 21
November 2008. November 2008.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
Language (MSML)", RFC 5707, February 2010. Language (MSML)", RFC 5707, February 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[W3C.REC-voicexml21-20070619] [W3C.REC-voicexml21-20070619]
Rehor, K., Bodell, M., Burke, D., Baggia, P., Auburn, R., Porter, B., McGlashan, S., Lee, A., Auburn, R., Carter,
Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee, J., Rehor, K., Oshry, M., Bodell, M., Burke, D., Baggia,
A., Porter, B., and M. Oshry, "Voice Extensible Markup P., Candell, E., and D. Burnett, "Voice Extensible Markup
Language (VoiceXML) 2.1", World Wide Web Consortium Language (VoiceXML) 2.1", World Wide Web Consortium
Recommendation REC-voicexml21-20070619, June 2007, Recommendation REC-voicexml21-20070619, June 2007,
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>. <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[I-D.ietf-speechsc-mrcpv2] [I-D.ietf-speechsc-mrcpv2]
Burnett, D. and S. Shanmugham, "Media Resource Control Burnett, D. and S. Shanmugham, "Media Resource Control
Protocol Version 2 (MRCPv2)", Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-21 (work in progress), draft-ietf-speechsc-mrcpv2-21 (work in progress),
July 2010. July 2010.
 End of changes. 16 change blocks. 
34 lines changed or deleted 36 lines changed or added

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