draft-ietf-sipcore-info-events-07.txt   draft-ietf-sipcore-info-events-08.txt 
SIPCORE C. Holmberg SIPCORE C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: RFC 2976 E. Burger Obsoletes: 2976 (if approved) E. Burger
(if approved) NeuStar, Inc. Intended status: Standards Track NeuStar, Inc.
Intended status: Standards Track H. Kaplan Expires: November 20, 2010 H. Kaplan
Expires: August 5, 2010 Acme Packet Acme Packet
February 1, 2010 May 19, 2010
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-07 draft-ietf-sipcore-info-events-08
Abstract Abstract
This document defines a method, INFO, for the Session Initiation This document defines a method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261], and an Info Package mechanism. The Protocol (SIP), and an Info Package mechanism. The document
document obsoletes [RFC2976]. For backward compatibility the obsoletes RFC 2976. For backward compatibility the document also
document also specifies a "legacy" mode of usage of the INFO method specifies a "legacy" mode of usage of the INFO method that is
that is compatible with the usage previously defined in [RFC2976], compatible with the usage previously defined in RFC 2976, referred to
referred to as "legacy INFO Usage" in this document. as "legacy INFO Usage" in this document.
Conventions Used in this Document Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 20, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2010.
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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 5
3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 6
3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 7
3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 7
3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 7
3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 7
3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8
4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 8
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 10
4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 10
4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 11
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11
6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14
6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14
7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 7. Info Package Considerations . . . . . . . . . . . . . . . . . 14
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14
7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 7.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15
7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 7.3.1. Alternative SIP signaling plane mechanisms . . . . . . 15
7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 7.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16
7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 7.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17
7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18
9.3. Co-existence with Info Package based INFO usage . . . . . 19 9.3. Co-existence with Info Package based INFO usage . . . . . 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 . . . . . . . . . . . . . . . . . . . . 20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 4, line 38 skipping to change at page 3, line 48
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 33 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 33
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34
A.7. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document defines a method, INFO, for the Session Initiation This document defines a method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261]. Protocol (SIP) [RFC3261].
The purpose of the INFO message is to carry application level The purpose of the INFO message is to carry application level
information between endpoints, using the SIP dialog signaling path. information between endpoints, using the SIP dialog signaling path.
Note that the INFO method is not used to update characteristics of a Note that the INFO method is not used to update characteristics of a
SIP dialog or session, but to allow the applications which use the SIP dialog or session, but to allow the applications which use the
skipping to change at page 6, line 49 skipping to change at page 5, line 49
The INFO request MUST NOT contain a Recv-Info header field. A UA can The INFO request MUST NOT contain a Recv-Info header field. A UA can
only indicate a set of Info Packages for which it is willing to only indicate a set of Info Packages for which it is willing to
receive INFO requests by using the SIP methods (and their responses) receive INFO requests by using the SIP methods (and their responses)
listed in Section 4. listed in Section 4.
A UA MUST NOT send an INFO request outside an invite dialog usage and A UA MUST NOT send an INFO request outside an invite dialog usage and
MUST NOT send an INFO request for an Info Package inside an invite MUST NOT send an INFO request for an Info Package inside an invite
dialog usage if the remote UA has not indicated willingness to dialog usage if the remote UA has not indicated willingness to
receive that Info-Package within that dialog. receive that Info-Package within that dialog.
If a UA receives a 469 (Bad INFO Package) response to an INFO If a UA receives a 469 (Bad Info Package) response to an INFO
request, based on [RFC5057] the response represents a Transaction request, based on [RFC5057] the response represents a Transaction
Only failure, and the UA MUST NOT terminate the invite dialog usage. Only failure, and the UA MUST NOT terminate the invite dialog usage.
Due to the possibility of forking, the UA which sends the initial Due to the possibility of forking, the UA which sends the initial
INVITE request MUST be prepared to receive INFO requests from INVITE request MUST be prepared to receive INFO requests from
multiple remote UAs during the early dialog phase. In addition, the multiple remote UAs during the early dialog phase. In addition, the
UA MUST be prepared to receive different Recv-Info header field UA MUST be prepared to receive different Recv-Info header field
values from different remote UAs. values from different remote UAs.
NOTE: If the UAS (receiver of the initial INVITE request) sends an NOTE: If the UAS (receiver of the initial INVITE request) sends an
skipping to change at page 7, line 25 skipping to change at page 6, line 25
the UAC before the dialog creating response, and might therefore be the UAC before the dialog creating response, and might therefore be
rejected by the UAC. In addition, an INFO request might be rejected rejected by the UAC. In addition, an INFO request might be rejected
due to a race condition, if a UA sends the INFO request at the same due to a race condition, if a UA sends the INFO request at the same
time as the remote UA sends a new set of Info Packages for which it time as the remote UA sends a new set of Info Packages for which it
is willing to receive INFO requests. is willing to receive INFO requests.
3.2.2. INFO Request Receiver 3.2.2. INFO Request Receiver
If a UA receives an INFO request associated with an Info Package that If a UA receives an INFO request associated with an Info Package that
the UA has not indicated willingness to receive, the UA MUST send a the UA has not indicated willingness to receive, the UA MUST send a
469 (Bad INFO Package) response (see Section 11.6), which contains a 469 (Bad Info Package) response (see Section 11.6), which contains a
Recv-Info header field with Info Packages for which the UA is willing Recv-Info header field with Info Packages for which the UA is willing
to receive INFO requests. The UA MUST NOT use the response to update to receive INFO requests. The UA MUST NOT use the response to update
the set of Info Packages, but simply to indicate the current set. In the set of Info Packages, but simply to indicate the current set. In
the terminology of Multiple Dialog Usages [RFC5057], this represents the terminology of Multiple Dialog Usages [RFC5057], this represents
a Transaction Only failure, and does not terminate the invite dialog a Transaction Only failure, and does not terminate the invite dialog
usage. usage.
If a UA receives an INFO request associated with an Info Package and If a UA receives an INFO request associated with an Info Package and
the message body part with Content-Disposition 'Info-Package' (see the message body part with Content-Disposition 'Info-Package' (see
Section 3.3.1) has a MIME type that the UA supports but not in the Section 3.3.1) has a Multipurpose Internet Mail Extensions (MIME)
context of that Info Package, it is RECOMMENDED that the UA send a type that the UA supports but not in the context of that Info
415 (Unsupported Media Type) response. Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media
Type) response.
The UA MAY send other error responses, such as Request Failure (4xx), The UA MAY send other error responses, such as Request Failure (4xx),
Server Failure (5xx) and Global Failure (6xx), in accordance with the Server Failure (5xx) and Global Failure (6xx), in accordance with the
error handling procedures in [RFC3261]. error handling procedures in [RFC3261].
Otherwise, if the INFO request is syntactically correct and well Otherwise, if the INFO request is syntactically correct and well
structured, the UA MUST send a 200 (OK) response. structured, the UA MUST send a 200 (OK) response.
NOTE: If the application needs to reject the information which it NOTE: If the application needs to reject the information which it
received in an INFO request, that needs to be done on the application received in an INFO request, that needs to be done on the application
level. Ie the application needs to trigger a new INFO request, which level. I.e. the application needs to trigger a new INFO request,
contains information that the previously received application data which contains information that the previously received application
was not accepted. Individual Info Package specifications need to data was not accepted. Individual Info Package specifications need
describe the details for such procedures. to describe the details for such procedures.
3.2.3. SIP Proxies 3.2.3. SIP Proxies
Proxies need no additional behavior beyond that described in Proxies need no additional behavior beyond that described in
[RFC3261] to support INFO. [RFC3261] to support INFO.
3.3. INFO Message Body 3.3. INFO Message Body
3.3.1. INFO Request Message Body 3.3.1. INFO Request Message Body
skipping to change at page 9, line 34 skipping to change at page 8, line 39
4.2.1. General 4.2.1. General
This section describes how a UA handles Info Packages, how a UA uses This section describes how a UA handles Info Packages, how a UA uses
the Recv-Info header field, and how the UA acts in re-INVITE rollback the Recv-Info header field, and how the UA acts in re-INVITE rollback
situations. situations.
4.2.2. UA Procedures 4.2.2. UA Procedures
A UA which supports the Info Package mechanism MUST indicate, using A UA which supports the Info Package mechanism MUST indicate, using
the Recv-Info header field, the set of Info Packages for which it is the Recv-Info header field, the set of Info Packages for which it is
willing to receive INFO requests. A UA can list multiple Info willing to receive INFO requests for a specific session. A UA can
Packages in a single Recv-Info header field, and the UA can use list multiple Info Packages in a single Recv-Info header field, and
multiple Recv-Info header fields. A UA can use an empty Recv-Info the UA can use multiple Recv-Info header fields. A UA can use an
header field, ie a header field without any header field values. empty Recv-Info header field, i.e. a header field without any header
field values.
A UA provides its set of Info Packages for which it is willing to A UA provides its set of Info Packages for which it is willing to
receive INFO requests during the dialog establishment. A UA can receive INFO requests during the dialog establishment. A UA can
update the set of Info Packages during the invite dialog usage. update the set of Info Packages during the invite dialog usage.
If a UA is not willing to receive INFO requests for any Info If a UA is not willing to receive INFO requests for any Info
Packages, during dialog establishment or later during the invite Packages, during dialog establishment or later during the invite
dialog usage, the UA MUST indicate this by including an empty Recv- dialog usage, the UA MUST indicate this by including an empty Recv-
Info header field. This informs other UAs that the UA still supports Info header field. This informs other UAs that the UA still supports
the Info Package mechanism. the Info Package mechanism.
skipping to change at page 10, line 31 skipping to change at page 9, line 36
that the remote UA is willing to receive INFO requests for that Info that the remote UA is willing to receive INFO requests for that Info
Package, or after the UA has received an indication that the remote Package, or after the UA has received an indication that the remote
UA is no longer willing to receive INFO requests associated with that UA is no longer willing to receive INFO requests associated with that
Info Package. Info Package.
NOTE: When a UA sends a message which contains a Recv-Info header NOTE: When a UA sends a message which contains a Recv-Info header
field with a new set of Info Packages for which the UA is willing to field with a new set of Info Packages for which the UA is willing to
receive INFO requests the remote UA might, before it receives the receive INFO requests the remote UA might, before it receives the
message, send an INFO request based on the old set of Info Packages. message, send an INFO request based on the old set of Info Packages.
In this case the receiver of the INFO requests rejects, and sends a In this case the receiver of the INFO requests rejects, and sends a
469 (Bad INFO Package) response to, the INFO request. 469 (Bad Info Package) response to, the INFO request.
If a UA indicates multiple Info Packages, which provide similar If a UA indicates multiple Info Packages, which provide similar
functionality, it is not possible to indicate a priority order of the functionality, it is not possible to indicate a priority order of the
Info Packages, or to indicate that the UA wishes to only receive INFO Info Packages, or to indicate that the UA wishes to only receive INFO
requests for one of the Info Packages. It is up to the application requests for one of the Info Packages. It is up to the application
logic associated with the Info Packages, and specific Info Package logic associated with the Info Packages, and specific Info Package
specifications, to describe application behavior in such cases. specifications, to describe application behavior in such cases.
For backward compatibility purpose, even if a UA indicates support of For backward compatibility purpose, even if a UA indicates support of
the Info Package mechanism, it is still allowed to enable legacy INFO the Info Package mechanism, it is still allowed to enable legacy INFO
usages Appendix A. In addition, if a UA indicates support of the usages Section 9. In addition, if a UA indicates support of the INFO
INFO method using the Allow header field [RFC3261], it does not method using the Allow header field [RFC3261], it does not implicitly
implicitly indicate support of the Info Package mechanism. A UA MUST indicate support of the Info Package mechanism. A UA MUST use the
use the Recv-Info header field in order to indicate that it supports Recv-Info header field in order to indicate that it supports the Info
the Info Package mechanism. Likewise, even if a UA uses the Recv- Package mechanism. Likewise, even if a UA uses the Recv-Info header
Info header field to indicate that it supports the Info Package field to indicate that it supports the Info Package mechanism, in
mechanism, in addition the UA still indicates support of the INFO addition the UA still indicates support of the INFO method using the
method using the Allow header. Allow header.
This document does not define a SIP option tag [RFC3261] for the Info This document does not define a SIP option tag [RFC3261] for the Info
Package mechanism. However, an Info Package specification can define Package mechanism. However, an Info Package specification can define
an option-tag associated with the specific Info Package, as described an option-tag associated with the specific Info Package, as described
in Section 10.6. in Section 10.6.
4.2.3. Recv-Info header field rules 4.2.3. Recv-Info header field rules
The text below defines rules on when a UA is required to include a The text below defines rules on when a UA is required to include a
Recv-Info header field in SIP messages. Section 6.1 lists the SIP Recv-Info header field in SIP messages. Section 6.1 lists the SIP
skipping to change at page 11, line 36 skipping to change at page 10, line 41
associated request did not contain a Recv-Info header field. associated request did not contain a Recv-Info header field.
NOTE: Different from the rules for generating SDP answers [RFC3264], NOTE: Different from the rules for generating SDP answers [RFC3264],
the receiver of a request which contains a set of Info Packages is the receiver of a request which contains a set of Info Packages is
not restricted to generate its own set of Info Packages as a subset not restricted to generate its own set of Info Packages as a subset
of the Info Package set received in the Info Package header field of of the Info Package set received in the Info Package header field of
the request. the request.
Similar to SDP answers, the receiver can include the same Recv-Info Similar to SDP answers, the receiver can include the same Recv-Info
header field value in multiple responses (18x/2xx) for the same header field value in multiple responses (18x/2xx) for the same
INVITE/re-INVITE transaction, but the receiver MUST NOT include a INVITE/re-INVITE transaction, but the receiver MUST use the same
Recv-Info header field value which is different from a value that the Recv-Info header field value (if included) in all responses for the
receiver has already included in a response for the same transaction. same transaction.
4.2.4. Info Package fallback rules 4.2.4. Info Package fallback rules
If the receiver of a request which contains a Recv-Info header field If the receiver of a request which contains a Recv-Info header field
rejects the request, both the sender and receiver of the request MUST rejects the request, both the sender and receiver of the request MUST
roll back to the set of Info Packages which was used before the roll back to the set of Info Packages which was used before the
request was sent. This also applies to the case where the receiver request was sent. This also applies to the case where the receiver
of an INVITE/re-INVITE request has included a Recv-Info header field of an INVITE/re-INVITE request has included a Recv-Info header field
in a provisional response, but later rejects the request. in a provisional response, but later rejects the request.
skipping to change at page 14, line 45 skipping to change at page 14, line 8
* Not applicable to INFO requests and responses associated with * Not applicable to INFO requests and responses associated with
legacy INFO usages. legacy INFO usages.
** Mandatory in at least one reliable 18x/2xx response, if sent, ** Mandatory in at least one reliable 18x/2xx response, if sent,
to the INVITE request, if the associated INVITE request contained to the INVITE request, if the associated INVITE request contained
a Recv-Info header field. a Recv-Info header field.
*** Mandatory if the associated request contained a Recv-Info *** Mandatory if the associated request contained a Recv-Info
header field. header field.
As defined in section 20 of RFC 3261 [RFC3261], a "mandatory"
header field MUST be present in a request, and MUST be understood
by the UAS receiving the request."
6.2. Info-Package header field 6.2. Info-Package header field
This document adds Info-Package to the definition of the element This document adds Info-Package to the definition of the element
"message-header" in the SIP message grammar [RFC3261]. Section 3 "message-header" in the SIP message grammar [RFC3261]. Section 3
describes the Info-Package header field usage. describes the Info-Package header field usage.
For the purposes of matching Info Package types indicated in Recv- For the purposes of matching Info Package types indicated in Recv-
Info with those in the Info-Package header field value, one compares Info with those in the Info-Package header field value, one compares
the Info-package-name portion of the Info-package-type portion of the the Info-package-name portion of the Info-package-type portion of the
Info-Package header field octet-by-octet with that of the Recv-Info Info-Package header field octet-by-octet with that of the Recv-Info
skipping to change at page 15, line 40 skipping to change at page 15, line 5
7.2. Appropriateness of Info Package Usage 7.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.
7.3. INFO Request Rate and Volume 7.3. Alternative Mechanisms
7.3.1. Alternative SIP signaling plane mechanisms
7.3.1.1. General
This subsection describes some alternative mechanisms for
transporting application information on the SIP signaling plane,
using SIP messages.
7.3.1.2. INFO Request Rate and Volume
INFO messages differ from many other sorts of SIP messages in that
they carry application information, and the size and rate of the INFO
message is directly determined by the application. This can cause
application information traffic to interfere with other traffic on
that infrastructure, or to self-interfere when data rates become too
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
exchanged during the lifetime a normal SIP session is rather small. exchanged during the lifetime a normal SIP session is rather small.
Some applications, like sending of DTMF tones, can generate a burst Some applications, like sending of Dual-Tone Multi-Frequency (DTMF)
of up to 20 messages per second. Other applications, like constant tones, can generate a burst of up to 20 messages per second. Other
GPS location updates, could generate a high rate of INFO requests applications, like constant GPS location updates, could generate a
during the lifetime of the invite dialog usage. high rate of INFO requests during the lifetime of the invite dialog
usage.
A designer of an Info Package, and the application that uses it, need
to consider the impact that the size and the rate of the INFO
messages have on the network and on other traffic, since it normally
cannot be ensured that INFO messages will be carried over a
congestion-controlled transport protocol end-to-end. Even if an INFO
message is sent over such a transport protocol, a downstream SIP
entity might forward the message over a transport protocol that does
not provide congestion control.
Furthermore, SIP messages tend to be relatively small, on the order Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
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 UDP MTU [RFC0768]. Appropriate mechanisms for plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768].
such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media Appropriate mechanisms for such traffic include the Hypertext
plane data transport mechanisms. Transfer Protocol (HTTP) [RFC2616], the Message Session Relay
Protocol (MSRP) [RFC4975], or other media plane data transport
7.4. Alternative Mechanisms mechanisms.
7.4.1. Alternative SIP signaling plane mechanisms
7.4.1.1. General
This subsection describes some alternative mechanisms for RFC 5405 [RFC5405] provides additional guidelines for applications
transporting application information on the SIP signaling plane, using UDP that may be useful background reading.
using SIP messages.
7.4.1.2. SUBSCRIBE/NOTIFY 7.3.1.3. 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 17, line 6 skipping to change at page 16, line 40
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.
7.4.1.3. MESSAGE 7.3.1.4. 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.
7.4.2. Media Plane Mechanisms 7.3.2. Media Plane Mechanisms
7.4.2.1. General 7.3.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.
7.4.2.2. MRCPv2 7.3.2.2. MRCP
One mechanism for media plane exchange of application data is MRCPv2 One mechanism for media plane exchange of application data is the
[I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2],
channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is where a media plane connection-oriented channel, such as a
established. Transmission Control Protocol (TCP) [RFC0793] or Stream Control
Transmission Protocol (SCTP) [RFC4960] stream is established.
7.4.2.3. MRSP 7.3.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.
7.4.3. Non-SIP related mechanisms 7.3.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.
8. Syntax 8. Syntax
skipping to change at page 18, line 38 skipping to change at page 18, line 28
9. Legacy INFO Usage 9. Legacy INFO Usage
9.1. General 9.1. General
A number of applications, standardized and proprietary, make use of A number of applications, standardized and proprietary, make use of
the INFO method as it was previously defined in [RFC2976], referred the INFO method as it was previously defined in [RFC2976], referred
to as "legacy INFO usage". to as "legacy INFO usage".
For backward compatibility purpose, this document does not deprecate For backward compatibility purpose, this document does not deprecate
such usages, and does not mandate users to define Info Packages for such usages, and does not mandate users to define Info Packages for
such usages. However, any new usage of INFO SHALL use the Info such usages. However, it is strongly RECOMMENDED that any new usage
Package mechanism defined in this specification. uses the Info Package mechanism defined in this specification, since
it does not share the issues associated with legacy INFO usage, and
since Info Packages can be registered with IANA.
9.2. Problems 9.2. Problems
While legacy INFO usage has been widely adopted for specific While legacy INFO usage has been widely adopted for specific
application use cases, [RFC2976] did not define a mechanism for SIP application use cases, [RFC2976] did not define a mechanism for SIP
UAs to indicate for which types of applications and contexts they UAs to indicate for which types of applications and contexts they
support the INFO method. In addition, [RFC2976] did not provide a support the INFO method. In addition, [RFC2976] did not provide a
mechanism to explicitly indicate the type of application and context mechanism to explicitly indicate the type of application and context
for which a specific INFO message is associated. for which a specific INFO message is associated.
skipping to change at page 19, line 28 skipping to change at page 19, line 20
Due to the problems described above, legacy INFO usages often require Due to the problems described above, legacy INFO usages often require
static configuration about for what type of applications and contexts static configuration about for what type of applications and contexts
UAs support the INFO method, and the way they handle application UAs support the INFO method, and the way they handle application
information transported in INFO messages. That has caused information transported in INFO messages. That has caused
interoperability problems in the industry. Therefore, a need for a interoperability problems in the industry. Therefore, a need for a
well defined and documented description of what the information sent well defined and documented description of what the information sent
in the INFO is used for has been identified. This situation is in the INFO is used for has been identified. This situation is
analogous to the context issue in Internet Mail [RFC3458]. analogous to the context issue in Internet Mail [RFC3458].
Section 4.1 describes how the Info Package mechanisms solves the
issues associated with legacy INFO usages.
9.3. Co-existence with Info Package based INFO usage 9.3. Co-existence with Info Package based INFO usage
As described in Section 3, an INFO request associated with an Info As described in Section 3, an INFO request associated with an Info
Package always contains an Info-Package header field. A UA MUST NOT Package always contains an Info-Package header field. A UA MUST NOT
insert an Info-Package header field in a legacy INFO request. insert an Info-Package header field in a legacy INFO request.
UAs are allowed to enable both legacy INFO usages and Info Package UAs are allowed to enable both legacy INFO usages and Info Package
usages as part of the same invite dialog usage. usages as part of the same invite dialog usage. However, UAs SHALL
NOT mix legacy INFO usages and Info Package usages in order to
transport the same application level information. If possible, UAs
SHALL prefer the usage of an Info Package.
See Appendix A for examples of existing legacy INFO usages. See Appendix A for examples of existing legacy INFO usages.
10. Info Package Requirements 10. Info Package Requirements
10.1. General 10.1. General
This section provides guidance on how to define an Info Package, and This section provides guidance on how to define an Info Package, and
what information needs to exist in an Info Package specification. what information needs to exist in an Info Package specification.
skipping to change at page 20, line 15 skipping to change at page 20, line 13
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 7.4 describes alternative mechanisms, which should be Section 7.3 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 21, line 29 skipping to change at page 21, line 27
name (see Section 10.4. name (see Section 10.4.
The Info Package specification MUST define the syntax and semantics The Info Package specification MUST define the syntax and semantics
of the defined parameters. In addition, the specification MUST of the defined parameters. In addition, the specification MUST
define whether a specific parameter is only applicable to the Recv- define whether a specific parameter is only applicable to the Recv-
Info header field, the Info-Package header field, or both. Info header field, the Info-Package header field, or both.
By default, an Info Package parameter is only applicable for the Info By default, an Info Package parameter is only applicable for the Info
Package for which the parameter has been explicitly defined. Package for which the parameter has been explicitly defined.
NOTE: Info Package parameters defined for specific Info Packages can Info Package parameters defined for specific Info Packages can share
share the name with parameters defined for other Info Packages, but the name with parameters defined for other Info Packages, but the
the parameter semantics are specific to the Info Package for which parameter semantics are specific to the Info Package for which they
they are defined. are defined. However, when choosing the name of a parameter it is
RECOMMENDED to not use the same name as an existing parameter for
another Info Package, if the semantics of the parameters are
different.
10.6. SIP Option Tags 10.6. SIP Option Tags
The Info Package specification MAY define SIP option tags, which can The Info Package specification MAY define SIP option tags, which can
be used as described in [RFC3261]. be used as described in [RFC3261].
The registration requirements for option tags are defined in The registration requirements for option tags are defined in
[I-D.peterson-rai-rfc3427bis]. [RFC5727].
10.7. INFO Message Body Parts 10.7. INFO Message Body Parts
The Info Package specification MUST define which message body part The Info Package specification MUST define which message body part
MIME types are associated with the Info Package. The specification MIME types are associated with the Info Package. The specification
MUST either define those body parts, which include the syntax, MUST either define those body parts, which include the syntax,
semantics and MIME type of the each body part, or refer to other semantics and MIME type of the each body part, or refer to other
documents which define the body parts. documents which define the body parts.
If multiple message body part MIME types are associated with an Info If multiple message body part MIME types are associated with an Info
skipping to change at page 22, line 42 skipping to change at page 22, line 44
Package specification MUST document the rate values. Package specification MUST document the rate values.
If the rates can vary, the Info Package specification MAY define Info If the rates can vary, the Info Package specification MAY define Info
Package parameters that UAs can use to indicate or negotiate the Package parameters that UAs can use to indicate or negotiate the
rates. Alternatively the rate information can be part of the rates. Alternatively the rate information can be part of the
application data information associated with the Info Package. application data information associated with the Info Package.
10.10. Info Package Security Considerations 10.10. Info Package Security Considerations
If the application information carried in INFO requests associated If the application information carried in INFO requests associated
with the Info Package requires certain level of security, the Info with the Info Package requires a certain level of security, the Info
Package specification MUST describe the mechanisms that UAs need to Package specification MUST describe the mechanisms that UAs need to
use in order to provide the required security. use in order to provide the required security.
If the Info Package specification does not require any additional If the Info Package specification does not require any additional
security, other than what the underlying SIP protocol provides, it security, other than what the underlying SIP protocol provides, it
MUST be stated in the Info Package specification. MUST be stated in the Info Package specification.
NOTE: In some cases, it may not be sufficient to mandate TLS in order NOTE: In some cases, it may not be sufficient to mandate TLS in order
to secure the Info Package payload, since intermediaries will have to secure the Info Package payload, since intermediaries will have
access to the payload, and beyond the first hop, there is no way to access to the payload, and beyond the first hop, there is no way to
skipping to change at page 24, line 39 skipping to change at page 24, line 42
The policy for review of Info Packages is "Specification Required", The policy for review of Info Packages is "Specification Required",
as defined in [RFC5226]. This policy was selected because Info as defined in [RFC5226]. This policy was selected because Info
Packages re-use an existing mechanism for transport of arbitrary Packages re-use an existing mechanism for transport of arbitrary
session-associated data within SIP, and therefore new Info Packages session-associated data within SIP, and therefore new Info Packages
do not require the more extensive review required by specifications do not require the more extensive review required by specifications
that make fundamental protocol changes. However, the reviewer is that make fundamental protocol changes. However, the reviewer is
expected to verify that each Info Package registration is in fact expected to verify that each Info Package registration is in fact
consistent with this definition. Changes to the SIP protocol and consistent with this definition. Changes to the SIP protocol and
state machine are outside of the allowable scope for an Info Package state machine are outside of the allowable scope for an Info Package
and are governed by other procedures including and are governed by other procedures including [RFC5727] and its
[I-D.peterson-rai-rfc3427bis] and its successors, if any. successors, if any.
The following data elements populate the Info Package Registry. The following data elements populate the Info Package Registry.
o Info Package Name: The Info Package Name is a case insensitive o Info Package Name: The Info Package Name is a case-sensitive
token. In addition, IANA shall not register multiple Info Package token. In addition, IANA shall not register multiple Info Package
names that have identical case-insensitive values. names that have identical case-insensitive values.
o Reference: A reference to a specification which describes the Info o Reference: A reference to a specification which describes the Info
Package. Package.
The initial population of this table shall be: The initial population of this table shall be:
Name Reference Name Reference
11.5. Registration of the Info-Package Content-Disposition 11.5. Registration of the Info-Package Content-Disposition
skipping to change at page 25, line 21 skipping to change at page 25, line 21
Name: info-package Name: info-package
Description: the body contains information associated with an Description: the body contains information associated with an
Info Package Info Package
Reference: RFCXXXX Reference: RFCXXXX
11.6. SIP Response Code 469 Registration 11.6. SIP Response Code 469 Registration
Please register the following new response code in the Session Please register the following new response code in the Session
Initiation Protocol Parameters - Response Codes registry. Initiation Protocol Parameters - Response Codes registry.
Response Code: 469 Response Code: 469
Default Reason Phrase: Bad INFO Package Default Reason Phrase: Bad Info Package
Reference: RFCXXXX Reference: RFCXXXX
12. Examples 12. Examples
12.1. Indication for which Info Packages UAs are willing to receive 12.1. Indication for which Info Packages UAs are willing to receive
INFO requests INFO requests
12.1.1. Initial INVITE request 12.1.1. Initial INVITE request
The UAC sends an initial INVITE request, where the UAC indicates that The UAC sends an initial INVITE request, where the UAC indicates that
skipping to change at page 30, line 29 skipping to change at page 30, line 29
Content-length: 59 Content-length: 59
I am a foo-x message type, and I belong to Info Package foo I am a foo-x message type, and I belong to Info Package foo
--theboundary-- --theboundary--
13. Security Considerations 13. Security Considerations
By eliminating multiple usages of INFO messages without adequate By eliminating multiple usages of INFO messages without adequate
community review and by eliminating the possibility for rogue SIP UAs community review and by eliminating the possibility for rogue SIP UAs
from confusing another UA by purposely sending unrelated INFO from confusing another UA by purposely sending unrelated INFO
requests, we expect this document's clarification of the use of INFO requests, as described in Section 9.2, we expect this document's
to improve the security of the Internet. Whilst rogue UAs can still clarification of the use of INFO to improve the security of the
send unrelated INFO requests, this mechanism provides mechanisms for Internet. Whilst rogue UAs can still send unrelated INFO requests,
which the UAS and other security devices can filter for approved Info this mechanism provides mechanisms for which the UAS and other
Packages. security devices can associate INFO requests with Info Packages that
have been negotiated for a session.
If the content of the Info Package payload is private, UAs will need If the content of the Info Package payload is private, UAs will need
to use end-to-end encryption, such as S/MIME, to prevent access to to use end-to-end encryption, such as S/MIME, to prevent access to
the content. This is particularly important as transport of INFO is the content. This is particularly important as transport of INFO is
likely not to be end-to-end, but through SIP proxies and back-to-back likely not to be end-to-end, but through SIP proxies and back-to-back
user agents (B2BUA's), which the user may not trust. user agents (B2BUA's), which the user may not trust.
The INFO request transports application level information. One The INFO request transports application level information. One
implication of this is INFO messages may require a higher level of implication of this is INFO messages may require a higher level of
protection than the underlying SIP dialog signaling. In particular, protection than the underlying SIP dialog signaling. In particular,
skipping to change at page 31, line 41 skipping to change at page 31, line 42
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5621] Camarillo, G., "Message Body Handling in the Session [RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, September 2009. Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67,
RFC 5727, March 2010.
14.2. Informative References 14.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000. October 2000.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
skipping to change at page 32, line 50 skipping to change at page 33, line 8
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022, Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007. September 2007.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007. Initiation Protocol", RFC 5057, November 2007.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for
Media Control", RFC 5168, March 2008. Media Control", RFC 5168, March 2008.
[I-D.peterson-rai-rfc3427bis] [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
Peterson, J., Jennings, C., and R. Sparks, "Change Process for Application Designers", BCP 145, RFC 5405,
for the Session Initiation Protocol (SIP) and the Real- November 2008.
time Applications and Infrastructure Area",
draft-peterson-rai-rfc3427bis-04 (work in progress), [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
October 2009. Language (MSML)", RFC 5707, February 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[W3C.REC-voicexml21-20070619] [W3C.REC-voicexml21-20070619]
Lee, A., Burnett, D., Carter, J., Auburn, R., Candell, E., Porter, B., Oshry, M., Bodell, M., Rehor, K., McGlashan,
Porter, B., Oshry, M., McGlashan, S., Rehor, K., Bodell, S., Burke, D., Auburn, R., Candell, E., Burnett, D.,
M., Burke, D., and P. Baggia, "Voice Extensible Markup Carter, J., Baggia, P., and A. Lee, "Voice Extensible
Language (VoiceXML) 2.1", World Wide Web Consortium Markup 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]
Shanmugham, S. and D. Burnett, "Media Resource Control Shanmugham, S. and D. Burnett, "Media Resource Control
Protocol Version 2 (MRCPv2)", Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-20 (work in progress), draft-ietf-speechsc-mrcpv2-20 (work in progress),
August 2009. August 2009.
[I-D.saleem-msml]
Saleem, A. and G. Sharratt, "Media Server Markup Language
(MSML)", draft-saleem-msml-09 (work in progress),
July 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[Ecma-355] [Ecma-355]
"Standard ECMA-355 Corporate Telecommunication Networks - "Standard ECMA-355 Corporate Telecommunication Networks -
Tunnelling of QSIG over SIP", ECMA http:// Tunnelling of QSIG over SIP", ECMA http://
www.ecma-international.org/publications/standards/ www.ecma-international.org/publications/standards/
Ecma-355.htm, June 2008. Ecma-355.htm, June 2008.
Appendix A. Legacy INFO Usage Appendix A. Legacy INFO Usage
A.1. General A.1. General
This section provides examples of existing legacy INFO usages. The This section provides examples of existing legacy INFO usages. The
section is not meant to be a comprehensive catalog of legacy INFO section is not meant to be a comprehensive catalog of legacy INFO
usages, but it should give the reader a flavor for current legacy usages, but it should give the reader a flavor for current legacy
INFO usages. INFO usages.
A.2. ISUP A.2. ISUP
[RFC3372] specifies the encapsulation of ISUP in SIP message bodies. [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP
ITU-T and 3GPP have specified similar procedures. message bodies. ITU-T and 3GPP have specified similar procedures.
A.3. QSIG A.3. QSIG
[Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies.
A.4. MSCML A.4. MSCML
[RFC5022] specifies how INFO is used as a transport mechanism by the [RFC5022] specifies how INFO is used as a transport mechanism by the
MSCML protocol. MSCML uses an option-tag in the Require header field Media Server Control Markup Language (MSCML) protocol. MSCML uses an
to ensure that the receiver understands the INFO content. option-tag in the Require header field to ensure that the receiver
understands the INFO content.
A.5. MSML A.5. MSML
[I-D.saleem-msml] specifies how INFO us used as a transport mechanism [RFC5707] specifies how INFO us used as a transport mechanism by the
by the MSML protocol. Media Server Markup Language (MSML) protocol.
A.6. Video Fast Update A.6. Video Fast Update
Companies have been using INFO messages in order to request fast Companies have been using INFO messages in order to request fast
video update. Currently a standardized mechanism, based on RTCP, has video update. Currently a standardized mechanism, based on RTCP, has
been specified in [RFC5168] been specified in [RFC5168]
A.7. DTMF
Companies have been using INFO messages in order to transport DTMF
tones. All mechanisms are proprietary, and have not been
standardized.
Appendix B. Acknowledgements Appendix B. Acknowledgements
The work on this document was influenced by the "INFO Considered The work on this document was influenced by the "INFO Considered
Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and
by the "Packaging and Negotiation of INFO Methods for the Session by the "Packaging and Negotiation of INFO Methods for the Session
Initiation Protocol" draft (15 January 2003) written by Dean Willis. Initiation Protocol" draft (15 January 2003) written by Dean Willis.
The following individuals have been involved in the work, and have The following individuals have been involved in the work, and have
provided input and feedback on this document: provided input and feedback on this document:
Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben
skipping to change at page 35, line 17 skipping to change at page 35, line 23
to prepare this document for publication. to prepare this document for publication.
Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided
valuable input in order to sort out the message body part usage for valuable input in order to sort out the message body part usage for
Info Packages. Info Packages.
Appendix C. Change Log Appendix C. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-info-events-08
o Further changes based on IESG comments
o Editorial changes
o Section 7.3 removed
o New section 7.4.1.2. added, containing text from old section 7.3
Changes from draft-ietf-sipcore-info-events-07
o Further changes based on WGLC comments
o Editorial changes
o IANA registry procedures clarified
o Reference to RFC 5727 added
Changes from draft-ietf-sipcore-info-events-05 Changes from draft-ietf-sipcore-info-events-05
o Further changes based on WGLC comments o Further changes based on WGLC comments
o Editorial changes o Editorial changes
o IANA registry procedures clarified o IANA registry procedures clarified
Changes from draft-ietf-sipcore-info-events-04 Changes from draft-ietf-sipcore-info-events-04
o Further changes based on WGLC comments o Further changes based on WGLC comments
o OPTIONS processing removed o OPTIONS processing removed
o Clarification of Recv-Info header field in INFO 469 response added o Clarification of Recv-Info header field in INFO 469 response added
o IANA registry procedures clarified o IANA registry procedures clarified
 End of changes. 52 change blocks. 
158 lines changed or deleted 212 lines changed or added

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