draft-ietf-sipcore-info-events-08.txt | draft-ietf-sipcore-info-events-09.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: November 20, 2010 H. Kaplan | Expires: April 1, 2011 H. Kaplan | |||
Acme Packet | Acme Packet | |||
May 19, 2010 | September 28, 2010 | |||
Session Initiation Protocol (SIP) INFO Method and Package Framework | Session Initiation Protocol (SIP) INFO Method and Package Framework | |||
draft-ietf-sipcore-info-events-08 | draft-ietf-sipcore-info-events-09 | |||
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 November 20, 2010. | This Internet-Draft will expire on April 1, 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Applicability and Backward Compatibility . . . . . . . . . . . 6 | |||
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 5 | 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 6 | 4.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 7 | |||
3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 7 | 4.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 8 | |||
3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 7 | 4.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 7 | 4.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 7 | 4.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 | |||
3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 | 4.3.2. INFO Response Message Body . . . . . . . . . . . . . . 9 | |||
4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 8 | 4.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 5. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 8 | 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 10 | |||
4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 8 | 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 10 | 5.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 10 | |||
4.2.4. Info Package fallback rules . . . . . . . . . . . . . 10 | 5.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 | |||
4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 11 | 5.2.4. Info Package fallback rules . . . . . . . . . . . . . 12 | |||
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11 | 5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 | |||
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 | |||
6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 | 6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 | ||||
6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14 | ||||
7. Info Package Considerations . . . . . . . . . . . . . . . . . 14 | ||||
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14 | 7.2. Info-Package header field . . . . . . . . . . . . . . . . 15 | |||
7.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15 | 7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16 | |||
7.3.1. Alternative SIP signaling plane mechanisms . . . . . . 15 | 8. Info Package Considerations . . . . . . . . . . . . . . . . . 16 | |||
7.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16 | 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
7.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 | 8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16 | |||
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8.3. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 | |||
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8.3.1. Alternative SIP signaling plane mechanisms . . . . . . 16 | |||
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18 | |||
9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 | 8.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19 | |||
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
9.3. Co-existence with Info Package based INFO usage . . . . . 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 . . . . . . . . . . . . . . . . . . . . 20 | 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 | |||
10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 | 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 22 | |||
10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 | 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 | |||
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 | 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 | |||
10.10. Info Package Security Considerations . . . . . . . . . . 22 | 10.10. Info Package Security Considerations . . . . . . . . . . 23 | |||
10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 | 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 | |||
10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 | 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 | |||
11.2. Registration of the Info-Package header field . . . . . . 24 | 11.2. Registration of the Info-Package header field . . . . . . 24 | |||
11.3. Registration of the Recv-Info header field . . . . . . . 24 | 11.3. Registration of the Recv-Info header field . . . . . . . 24 | |||
11.4. Creation of the Info Packages Registry . . . . . . . . . 24 | 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 | |||
11.5. Registration of the Info-Package Content-Disposition . . 25 | 11.5. Registration of the Info-Package Content-Disposition . . 25 | |||
11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 | 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 | |||
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
12.1. Indication for which Info Packages UAs are willing to | 12.1. Indication for which Info Packages UAs are willing to | |||
receive INFO requests . . . . . . . . . . . . . . . . . . 25 | receive INFO requests . . . . . . . . . . . . . . . . . . 25 | |||
12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 | 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 | |||
12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 | 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 | |||
12.2. INFO request associated with Info Package . . . . . . . . 27 | 12.2. INFO request associated with Info Package . . . . . . . . 27 | |||
12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 | 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 | |||
12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 | 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 28 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 | 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 31 | 14.2. Informative References . . . . . . . . . . . . . . . . . 32 | |||
Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 33 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 | |||
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 33 | Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | |||
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | ||||
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | ||||
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | ||||
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 | ||||
A.7. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | ||||
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 | ||||
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | 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 | |||
skipping to change at page 4, line 46 | skipping to change at page 4, line 46 | |||
NOTE: A UA can use an empty Recv-Info header field (a header field | NOTE: A UA can use an empty Recv-Info header field (a header field | |||
without a value) to indicate that it is not willing to receive INFO | without a value) to indicate that it is not willing to receive INFO | |||
requests for any Info-Package, but to inform other UAs that it still | requests for any Info-Package, but to inform other UAs that it still | |||
supports the Info Package mechanism. | supports the Info Package mechanism. | |||
When a UA sends an INFO request, it uses the Info-Package header | When a UA sends an INFO request, it uses the Info-Package header | |||
field to indicate which Info Package is associated with the request. | field to indicate which Info Package is associated with the request. | |||
One particular INFO request can only be associated with a single Info | One particular INFO request can only be associated with a single Info | |||
Package. | Package. | |||
2. Applicability | 2. Motivation | |||
A number of applications, standardized and proprietary, make use of | ||||
the INFO method as it was previously defined in RFC 2976 [RFC2976], | ||||
referred to as "legacy INFO usage". These include but are not | ||||
limited to: | ||||
o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part | ||||
(ISUP) in SIP message bodies. ITU-T and 3GPP have specified | ||||
similar procedures. | ||||
o [Ecma-355] specifies the encapsulation of QSIG in SIP message | ||||
bodies. | ||||
o RFC 5022 [RFC5022] specifies how INFO is used as a transport | ||||
mechanism by the Media Server Control Markup Language (MSCML) | ||||
protocol. MSCML uses an option-tag in the Require header field to | ||||
ensure that the receiver understands the INFO content. | ||||
o RFC 5707 [RFC5707] specifies how INFO us used as a transport | ||||
mechanism by the Media Server Markup Language (MSML) protocol. | ||||
o Companies have been using INFO messages in order to request fast | ||||
video update. Currently a standardized mechanism, based on RTCP, | ||||
has been specified in RFC 5168 [RFC5168]. | ||||
o Companies have been using INFO messages in order to transport DTMF | ||||
tones. All mechanisms are proprietary, and have not been | ||||
standardized. | ||||
Some legacy INFO usages are also recognized as being shortcuts to | ||||
more appropriate and flexible mechanisms. | ||||
Furthermore, RFC 2976 did not define mechanisms that would enable a | ||||
SIP UA to indicate (1) the types of applications and contexts in | ||||
which they support the INFO method or (2) the types of application | ||||
and context with which a specific INFO message is associated. | ||||
Because legacy INFO usages do not have associated Info Packages, it | ||||
is not possible to use the Recv-Info and Info-Package header fields | ||||
with legacy INFO usages. That is, a UA cannot use the Recv-Info | ||||
header field to indicate for which legacy INFO usages it is willing | ||||
to receive INFO requests, and a UA cannot use the Info-Package header | ||||
field to indicate for which legacy INFO usage an INFO request is | ||||
associated with. | ||||
Due to the problems described above, legacy INFO usages often require | ||||
static configuration about for what type of applications and contexts | ||||
UAs support the INFO method, and the way they handle application | ||||
information transported in INFO messages. That has caused | ||||
interoperability problems in the industry. | ||||
To overcome these problems, the SIP Working Group has spent | ||||
significant discussion time over many years coming to agreement on | ||||
whether it was more appropriate to fix INFO (by defining a | ||||
registration mechanism for the ways in which it was used) or to | ||||
deprecate it altogether (with the usage described in RFC 3398 | ||||
[RFC3398] being grandfathered as the sole legitimate usage). | ||||
Although it required substantial consensus building and concessions | ||||
by those more inclined to completely deprecate INFO, the eventual | ||||
direction of the working group was to publish a framework for | ||||
registration of INFO packages as defined in this specification. | ||||
3. Applicability and Backward Compatibility | ||||
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) [RFC3261], and an Info Package mechanism. The | |||
document obsoletes [RFC2976]. For backward compatibility the | document obsoletes RFC 2976 [RFC2976]. For backward compatibility, | |||
document also specifies a "legacy" mode of usage of the INFO method | the document also specifies a "legacy" mode of usage of the INFO | |||
that is compatible with the usage previously defined in [RFC2976], | method that is compatible with the usage previously defined in RFC | |||
referred to as "legacy INFO Usage" in this document. | 2976, referred to as "legacy INFO Usage". | |||
3. The INFO Method | For backward compatibility purposes, this document does not deprecate | |||
legacy INFO usages, and does not mandate users to define Info | ||||
Packages for such usages. However: | ||||
3.1. General | 1. A UA MUST NOT insert an Info-Package header field in a legacy | |||
INFO request (as described in Section 3, an INFO request | ||||
associated with an Info Package always contains an Info-Package | ||||
header field). | ||||
2. It is strongly RECOMMENDED that any new usage 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. | ||||
3. UAs are allowed to enable both legacy INFO usages and Info | ||||
Package usages as part of the same invite dialog usage, but 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. | ||||
4. The INFO Method | ||||
4.1. General | ||||
The INFO method provides a mechanism for transporting application | The INFO method provides a mechanism for transporting application | |||
level information that can further enhance a SIP application. Annex | level information that can further enhance a SIP application. Annex | |||
A gives more details on the types of applications for which the use | A gives more details on the types of applications for which the use | |||
of INFO is appropriate. | of INFO is appropriate. | |||
This section describes how a UA handles INFO requests and responses, | This section describes how a UA handles INFO requests and responses, | |||
as well as the message bodies included in INFO messages. | as well as the message bodies included in INFO messages. | |||
3.2. INFO Request | 4.2. INFO Request | |||
4.2.1. INFO Request Sender | ||||
3.2.1. INFO Request Sender | ||||
An INFO request can be associated with an Info Package (see | An INFO request can be associated with an Info Package (see | |||
Section 4), or associated with a legacy INFO usage (see Section 9). | Section 5), or associated with a legacy INFO usage (see Section 2). | |||
The construction of the INFO request is the same as any other non- | The construction of the INFO request is the same as any other non- | |||
target refresh request within an existing invite dialog usage as | target refresh request within an existing invite dialog usage as | |||
described in Section 12.2 of [RFC3261]. | described in Section 12.2 of RFC 3261. | |||
When a UA sends an INFO request associated with an Info Package, it | When a UA sends an INFO request associated with an Info Package, it | |||
MUST include an Info-Package header field that indicates which Info | MUST include an Info-Package header field that indicates which Info | |||
Package is associated with the request. A specific INFO request can | Package is associated with the request. A specific INFO request can | |||
be used only for a single Info Package. | be used only for a single Info Package. | |||
When a UA sends an INFO request associated with an legacy INFO usage | When a UA sends an INFO request associated with an legacy INFO usage | |||
there is no Info Package associated with the request, and the UA MUST | there is no Info Package associated with the request, and the UA MUST | |||
NOT include an Info-Package header field in the request. | NOT include an Info-Package header field in the request. | |||
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 5. | |||
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 RFC 5057 the response represents a Transaction Only | |||
Only failure, and the UA MUST NOT terminate the invite dialog usage. | 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 | |||
INFO request just after it has sent the response which creates the | INFO request just after it has sent the response which creates the | |||
dialog, the UAS needs to be prepared that the INFO request can reach | dialog, the UAS needs to be prepared that the INFO request can reach | |||
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 | 4.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 Multipurpose Internet Mail Extensions (MIME) | Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) | |||
type that the UA supports but not in the context of that Info | type that the UA supports but not in the context of that Info | |||
Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media | Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media | |||
Type) response. | 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 defined in RFC 3261. | |||
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. I.e. the application needs to trigger a new INFO request, | level. I.e. the application needs to trigger a new INFO request, | |||
which contains information that the previously received application | which contains information that the previously received application | |||
data was not accepted. Individual Info Package specifications need | data was not accepted. Individual Info Package specifications need | |||
to describe the details for such procedures. | to describe the details for such procedures. | |||
3.2.3. SIP Proxies | 4.2.3. SIP Proxies | |||
Proxies need no additional behavior beyond that described in | Proxies need no additional behavior beyond that described in RFC 3261 | |||
[RFC3261] to support INFO. | to support INFO. | |||
3.3. INFO Message Body | 4.3. INFO Message Body | |||
3.3.1. INFO Request Message Body | 4.3.1. INFO Request Message Body | |||
The purpose of the INFO request is to carry application level | The purpose of the INFO request is to carry application level | |||
information between SIP UAs. The application information data is | information between SIP UAs. The application information data is | |||
carried in the payload of the message body of the INFO request. | carried in the payload of the message body of the INFO request. | |||
NOTE: An INFO request associated with an Info Package can also | NOTE: An INFO request associated with an Info Package can also | |||
include information associated with the Info Package using Info- | include information associated with the Info Package using Info- | |||
Package header field parameters. | Package header field parameters. | |||
If an INFO request associated with an Info Package contains a message | If an INFO request associated with an Info Package contains a message | |||
body part, the body part is identified by a Content-Disposition | body part, the body part is identified by a Content-Disposition | |||
header field 'Info-Package' value. The body part can contain a | header field 'Info-Package' value. The body part can contain a | |||
single MIME type, or it can be a multipart [RFC5621] which contains | single MIME type, or it can be a multipart [RFC5621] which contains | |||
other body parts associated with the Info Package. | other body parts associated with the Info Package. | |||
UAs MUST support multipart body parts in accordance with [RFC5621]. | UAs MUST support multipart body parts in accordance with RFC 5621. | |||
NOTE: An INFO request can also contain other body parts that are | NOTE: An INFO request can also contain other body parts that are | |||
meaningful within the context of an invite dialog usage but are not | meaningful within the context of an invite dialog usage but are not | |||
specifically associated with the INFO method and the application | specifically associated with the INFO method and the application | |||
concerned. | concerned. | |||
When a UA supports a specific Info-Package, the UA MUST also support | When a UA supports a specific Info-Package, the UA MUST also support | |||
message body MIME types in accordance with that Info-Package. | message body MIME types in accordance with that Info-Package. | |||
However, in accordance with [RFC3261] the UA still indicates the | However, in accordance with RFC 3261 the UA still indicates the | |||
supported MIME types using the Accept header. | supported MIME types using the Accept header. | |||
3.3.2. INFO Response Message Body | 4.3.2. INFO Response Message Body | |||
A UA MUST NOT include a message body associated with an Info Package | A UA MUST NOT include a message body associated with an Info Package | |||
in an INFO response. Message bodies associated with Info Packages | in an INFO response. Message bodies associated with Info Packages | |||
MUST only be sent in INFO requests. | MUST only be sent in INFO requests. | |||
A UA MAY include a message body which is not associated with an Info | A UA MAY include a message body which is not associated with an Info | |||
Package in an INFO response. | Package in an INFO response. | |||
3.4. Order of Delivery | 4.4. Order of Delivery | |||
The Info Package mechanism does not define a delivery order | The Info Package mechanism does not define a delivery order | |||
mechanism. Info Packages can rely on the CSeq header field to detect | mechanism. Info Packages can rely on the CSeq header field to detect | |||
if an INFO request is received out of order. | if an INFO request is received out of order. | |||
If specific applications need additional mechanisms for order of | If specific applications need additional mechanisms for order of | |||
delivery, those mechanisms, and related procedures, are specified as | delivery, those mechanisms, and related procedures, are specified as | |||
part of the associated Info Package (e.g. the use of sequence numbers | part of the associated Info Package (e.g. the use of sequence numbers | |||
within the application data). | within the application data). | |||
4. Info Packages | 5. Info Packages | |||
4.1. General | 5.1. General | |||
An Info Package specification defines the content and semantics of | An Info Package specification defines the content and semantics of | |||
the information carried in an INFO message associated with an Info | the information carried in an INFO message associated with an Info | |||
Package. The Info Package mechanism provides a way for UAs to | Package. The Info Package mechanism provides a way for UAs to | |||
indicate for which Info Packages they are willing to receive INFO | indicate for which Info Packages they are willing to receive INFO | |||
requests, and which Info Package a specific INFO request is | requests, and which Info Package a specific INFO request is | |||
associated with. | associated with. | |||
4.2. User Agent Behavior | 5.2. User Agent Behavior | |||
4.2.1. General | 5.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 | 5.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 for a specific session. A UA can | willing to receive INFO requests for a specific session. A UA can | |||
list multiple Info Packages in a single Recv-Info header field, and | list multiple Info Packages in a single Recv-Info header field, and | |||
the UA can use multiple Recv-Info header fields. A UA can use an | the UA can use multiple Recv-Info header fields. A UA can use an | |||
empty Recv-Info header field, i.e. a header field without any header | empty Recv-Info header field, i.e. a header field without any header | |||
field values. | 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 | |||
skipping to change at page 9, line 47 | skipping to change at page 11, line 28 | |||
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 Section 9. In addition, if a UA indicates support of the INFO | usages. In addition, if a UA indicates support of the INFO method | |||
method using the Allow header field [RFC3261], it does not implicitly | using the Allow header field [RFC3261], it does not implicitly | |||
indicate support of the Info Package mechanism. A UA MUST use the | indicate support of the Info Package mechanism. A UA MUST use the | |||
Recv-Info header field in order to indicate that it supports the Info | Recv-Info header field in order to indicate that it supports the Info | |||
Package mechanism. Likewise, even if a UA uses the Recv-Info header | Package mechanism. Likewise, even if a UA uses the Recv-Info header | |||
field to indicate that it supports the Info Package mechanism, in | field to indicate that it supports the Info Package mechanism, in | |||
addition the UA still indicates support of the INFO method using the | addition the UA still indicates support of the INFO 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 | 5.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 7.1 lists the SIP | |||
methods, for which a UA can insert a Recv-Info header field in | methods, for which a UA can insert a Recv-Info header field in | |||
requests and responses. | requests and responses. | |||
- The sender of an initial INVITE request MUST include a Recv-Info | - The sender of an initial INVITE request MUST include a Recv-Info | |||
header field in the initial INVITE request, even if the sender is not | header field in the initial INVITE request, even if the sender is not | |||
willing to receive INFO requests associated with any Info Package. | willing to receive INFO requests associated with any Info Package. | |||
- The receiver of a request which contains a Recv-Info header field | - The receiver of a request which contains a Recv-Info header field | |||
MUST include a Recv-Info header field in a reliable 18x/2xx response | MUST include a Recv-Info header field in a reliable 18x/2xx response | |||
to the request, even if the request contains an empty Recv-Info | to the request, even if the request contains an empty Recv-Info | |||
skipping to change at page 10, line 45 | skipping to change at page 12, line 26 | |||
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 use the same | INVITE/re-INVITE transaction, but the receiver MUST use the same | |||
Recv-Info header field value (if included) in all responses for the | Recv-Info header field value (if included) in all responses for the | |||
same transaction. | same transaction. | |||
4.2.4. Info Package fallback rules | 5.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. | |||
NOTE: The dialog state rollback rules for Info Packages might differ | NOTE: The dialog state rollback rules for Info Packages might differ | |||
from the rules for other types of dialog state information (SDP, | from the rules for other types of dialog state information (SDP, | |||
target, etc). | target, etc). | |||
4.3. REGISTER Processing | 5.3. REGISTER Processing | |||
This document allows a UA to insert a Recv-Info header field in a | This document allows a UA to insert a Recv-Info header field in a | |||
REGISTER request. However, a UA SHALL NOT include a header value for | REGISTER request. However, a UA SHALL NOT include a header value for | |||
a specific Info Package unless the specific Info Package | a specific Info Package unless the specific Info Package | |||
specification describes how the header field value shall be | specification describes how the header field value shall be | |||
interpreted and used by the registrar, e.g. in order to determine | interpreted and used by the registrar, e.g. in order to determine | |||
request targets. | request targets. | |||
Rather than using the Recv-Info header field in order to determine | Rather than using the Recv-Info header field in order to determine | |||
request targets, it is recommended to use more appropriate | request targets, it is recommended to use more appropriate | |||
mechanisms, e.g. based on [RFC3840]. However, this document does not | mechanisms, e.g. based on RFC 3840 [RFC3840]. However, this document | |||
define a feature tag for the Info Package mechanism, or a mechanism | does not define a feature tag for the Info Package mechanism, or a | |||
to define feature tags for specific Info Packages. | mechanism to define feature tags for specific Info Packages. | |||
5. Formal INFO Method Definition | 6. Formal INFO Method Definition | |||
5.1. INFO Method | 6.1. INFO Method | |||
This document describes one new SIP method: INFO. This document | This document describes one new SIP method: INFO. This document | |||
replaces the definition and registrations found in [RFC2976]. | replaces the definition and registrations found in RFC 2976 | |||
[RFC2976]. | ||||
This table expands on Tables 2 and 3 in [RFC3261]. | This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. | |||
Header Where INFO | Header Where INFO | |||
------ ----- ---- | ------ ----- ---- | |||
Accept R o | Accept R o | |||
Accept 415 o | Accept 415 o | |||
Accept-Encoding R o | Accept-Encoding R o | |||
Accept-Encoding 2xx o | Accept-Encoding 2xx o | |||
Accept-Encoding 415 c | Accept-Encoding 415 c | |||
Accept-Language R o | Accept-Language R o | |||
Accept-Language 2xx o | Accept-Language 2xx o | |||
skipping to change at page 13, line 12 | skipping to change at page 14, line 39 | |||
To c m (w/ Tag) | To c m (w/ Tag) | |||
Unsupported 420 o | Unsupported 420 o | |||
User-Agent o | User-Agent o | |||
Via m | Via m | |||
Warning r o | Warning r o | |||
WWW-Authenticate 401 m | WWW-Authenticate 401 m | |||
WWW-Authenticate 407 o | WWW-Authenticate 407 o | |||
Figure 1: Table 1: Summary of Header Fields | Figure 1: Table 1: Summary of Header Fields | |||
6. INFO Header Fields | 7. INFO Header Fields | |||
6.1. General | 7.1. General | |||
This table expands on tables 2 and 3 in [RFC3261]. | This table expands on tables 2 and 3 in RFC 3261 [RFC3261]. | |||
Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD | Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD | |||
------------------------------------------------------------------ | ------------------------------------------------------------------ | |||
Info-Package R - - - - - - - m* - - | Info-Package R - - - - - - - m* - - | |||
Recv-Info R - - - m - o o - - o | Recv-Info R - - - m - o o - - o | |||
Recv-Info 2xx - - - o** - - o***- - o*** | Recv-Info 2xx - - - o** - - o***- - o*** | |||
Recv-Info 1xx - - - o** - - - - - - | Recv-Info 1xx - - - o** - - - - - - | |||
Recv-Info 469 - - - - - - - m* - - | Recv-Info 469 - - - - - - - m* - - | |||
Recv-Info r - - - o - - o - - o | Recv-Info r - - - o - - o - - o | |||
skipping to change at page 14, line 8 | skipping to change at page 15, line 38 | |||
* 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" | As defined in section 20 of RFC 3261, a "mandatory" header field | |||
header field MUST be present in a request, and MUST be understood | MUST be present in a request, and MUST be understood by the UAS | |||
by the UAS receiving the request." | receiving the request." | |||
6.2. Info-Package header field | 7.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 4 | |||
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 | |||
header field value. That is, the Info Package name is case | header field value. That is, the Info Package name is case | |||
sensitive. Info-package-param is not part of the comparison-checking | sensitive. Info-package-param is not part of the comparison-checking | |||
algorithm. | algorithm. | |||
This document does not define values for Info-Package types. | This document does not define values for Info-Package types. | |||
Individual Info Package specifications define these values. | Individual Info Package specifications define these values. | |||
6.3. Recv-Info header field | 7.3. Recv-Info header field | |||
This document adds Recv-Info to the definition of the element | This document adds Recv-Info to the definition of the element | |||
"message-header" in the SIP message grammar [RFC3261]. Section 4 | "message-header" in the SIP message grammar [RFC3261]. Section 5 | |||
describes the Recv-Info header field usage. | describes the Recv-Info header field usage. | |||
7. Info Package Considerations | 8. Info Package Considerations | |||
7.1. General | 8.1. General | |||
This section covers considerations to take into account when deciding | This section covers considerations to take into account when deciding | |||
whether the usage of an Info Package is appropriate for transporting | whether the usage of an Info Package is appropriate for transporting | |||
of application information for a specific use-case. | of application information for a specific use-case. | |||
7.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. | |||
7.3. Alternative Mechanisms | 8.3. Alternative Mechanisms | |||
7.3.1. Alternative SIP signaling plane mechanisms | 8.3.1. Alternative SIP signaling plane mechanisms | |||
7.3.1.1. General | 8.3.1.1. General | |||
This subsection describes some alternative mechanisms for | This subsection describes some alternative mechanisms for | |||
transporting application information on the SIP signaling plane, | transporting application information on the SIP signaling plane, | |||
using SIP messages. | using SIP messages. | |||
7.3.1.2. INFO Request Rate and Volume | 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 16, line 6 | skipping to change at page 17, line 37 | |||
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. | |||
7.3.1.3. SUBSCRIBE/NOTIFY | 8.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 16, line 40 | 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. | |||
7.3.1.4. MESSAGE | 8.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.3.2. Media Plane Mechanisms | 8.3.2. Media Plane Mechanisms | |||
7.3.2.1. General | 8.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.3.2.2. MRCP | 8.3.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. | |||
7.3.2.3. MRSP | 8.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.3.3. Non-SIP related mechanisms | 8.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 | 9. Syntax | |||
8.1. General | 9.1. General | |||
This section describes the syntax extensions to the ABNF syntax | This section describes the syntax extensions to the ABNF syntax | |||
defined in [RFC3261] required for the INFO method, and adds | defined in RFC 3261 required for the INFO method, and adds | |||
definitions for the Info-Package and Recv-Info header fields. The | definitions for the Info-Package and Recv-Info header fields. The | |||
previous sections describe the semantics. The ABNF defined in this | previous sections describe the semantics. The ABNF defined in this | |||
specification is conformant to [RFC5234]. | specification is conformant to RFC 5234 [RFC5234]. | |||
8.2. ABNF | 9.2. ABNF | |||
INFOm = %x49.4E.46.4F ; INFO in caps | INFOm = %x49.4E.46.4F ; INFO in caps | |||
Method =/ INFOm | Method =/ INFOm | |||
message-header =/ (Info-Package / Recv-Info) CRLF | message-header =/ (Info-Package / Recv-Info) CRLF | |||
Info-Package = "Info-Package" HCOLON Info-package-type | Info-Package = "Info-Package" HCOLON Info-package-type | |||
Recv-Info = "Recv-Info" HCOLON [Info-package-list] | Recv-Info = "Recv-Info" HCOLON [Info-package-list] | |||
Info-package-list = Info-package-type *( COMMA Info-package-type ) | Info-package-list = Info-package-type *( COMMA Info-package-type ) | |||
Info-package-type = Info-package-name *( SEMI Info-package-param) | Info-package-type = Info-package-name *( SEMI Info-package-param) | |||
Info-package-name = token | Info-package-name = token | |||
Info-package-param = generic-param | Info-package-param = generic-param | |||
9. Legacy INFO Usage | ||||
9.1. General | ||||
A number of applications, standardized and proprietary, make use of | ||||
the INFO method as it was previously defined in [RFC2976], referred | ||||
to as "legacy INFO usage". | ||||
For backward compatibility purpose, this document does not deprecate | ||||
such usages, and does not mandate users to define Info Packages for | ||||
such usages. However, it is strongly RECOMMENDED that any new usage | ||||
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 | ||||
While legacy INFO usage has been widely adopted for specific | ||||
application use cases, [RFC2976] did not define a mechanism for SIP | ||||
UAs to indicate for which types of applications and contexts they | ||||
support the INFO method. In addition, [RFC2976] did not provide a | ||||
mechanism to explicitly indicate the type of application and context | ||||
for which a specific INFO message is associated. | ||||
Example: If the Content-Type is "image/jpeg", the MIME-attached | ||||
content is a JPEG image. Still, there are many useful ways a UA can | ||||
render an image. The image could be a caller-id picture, a contact | ||||
icon, a photo for sharing, and so on. The sender does not know which | ||||
image to send to the receiver if the receiver supports an image | ||||
content type. Likewise, the receiver does not know the context of an | ||||
image the client is sending if the receiver supports receiving more | ||||
than one image content type. | ||||
Since legacy INFO usages do not have associated Info Packages, it is | ||||
not possible to use the Recv-Info and Info-Package header fields with | ||||
legacy INFO usages. That is, a UA cannot use the Recv-Info header | ||||
field to indicate for which legacy INFO usages it is willing to | ||||
receive INFO requests, and a UA cannot use the Info-Package header | ||||
field to indicate for which legacy INFO usage an INFO request is | ||||
associated with. | ||||
Due to the problems described above, legacy INFO usages often require | ||||
static configuration about for what type of applications and contexts | ||||
UAs support the INFO method, and the way they handle application | ||||
information transported in INFO messages. That has caused | ||||
interoperability problems in the industry. Therefore, a need for a | ||||
well defined and documented description of what the information sent | ||||
in the INFO is used for has been identified. This situation is | ||||
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 | ||||
As described in Section 3, an INFO request associated with an Info | ||||
Package always contains an Info-Package header field. A UA MUST NOT | ||||
insert an Info-Package header field in a legacy INFO request. | ||||
UAs are allowed to enable both legacy INFO usages and Info Package | ||||
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. | ||||
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. | |||
If, for an Info Package, there is a need to extend or modify the | If, for an Info Package, there is a need to extend or modify the | |||
behavior described in this document, that behavior MUST be described | behavior described in this document, that behavior MUST be described | |||
in the Info Package specification. It is bad practice for Info | in the Info Package specification. It is bad practice for Info | |||
skipping to change at page 20, line 13 | 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 7.3 describes alternative mechanisms, which should be | Section 8.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 20, line 48 | skipping to change at page 21, line 10 | |||
information. | information. | |||
Annex A provides more information, and describes alternative | Annex A provides more information, and describes alternative | |||
mechanisms which one should consider for solving a specific use-case. | mechanisms which one should consider for solving a specific use-case. | |||
10.4. Info Package Name | 10.4. Info Package Name | |||
The Info Package specification MUST define an Info Package name, | The Info Package specification MUST define an Info Package name, | |||
which UAs use as a header field value (e.g. "infoX") to identify the | which UAs use as a header field value (e.g. "infoX") to identify the | |||
Info Package in the Recv-Info and Info-Package header fields. The | Info Package in the Recv-Info and Info-Package header fields. The | |||
header field value MUST conform to the ABNF defined in Section 8.2. | header field value MUST conform to the ABNF defined in Section 9.2. | |||
The Info Package mechanism does not support package versioning. | The Info Package mechanism does not support package versioning. | |||
Specific Info Package message body payloads can contain version | Specific Info Package message body payloads can contain version | |||
information, which is handled by the applications associated with the | information, which is handled by the applications associated with the | |||
Info Package. However, such feature is outside the scope of the | Info Package. However, such feature is outside the scope of the | |||
generic Info Package mechanism. | generic Info Package mechanism. | |||
NOTE: Even if an Info Package name contains version numbering (e.g. | NOTE: Even if an Info Package name contains version numbering (e.g. | |||
foo_v2), the Info Package mechanism does not distinguish a version | foo_v2), the Info Package mechanism does not distinguish a version | |||
number from the rest of the Info Package name. | number from the rest of the Info Package name. | |||
skipping to change at page 21, line 38 | skipping to change at page 21, line 48 | |||
the name with parameters defined for other Info Packages, but the | the name with parameters defined for other Info Packages, but the | |||
parameter semantics are specific to the Info Package for which they | parameter semantics are specific to the Info Package for which they | |||
are defined. However, when choosing the name of a parameter it is | are defined. However, when choosing the name of a parameter it is | |||
RECOMMENDED to not use the same name as an existing parameter for | RECOMMENDED to not use the same name as an existing parameter for | |||
another Info Package, if the semantics of the parameters are | another Info Package, if the semantics of the parameters are | |||
different. | 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 RFC 3261. | |||
The registration requirements for option tags are defined in | The registration requirements for option tags are defined in RFC 5727 | |||
[RFC5727]. | [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. | |||
skipping to change at page 22, line 25 | skipping to change at page 22, line 35 | |||
Package, or whether the UA has to wait for the response for a | Package, or whether the UA has to wait for the response for a | |||
previous INFO request associated with the same Info Package. | previous INFO request associated with the same Info Package. | |||
There can also be restrictions related to whether UAs need to support | There can also be restrictions related to whether UAs need to support | |||
and use other SIP extensions and capabilities when they use the Info | and use other SIP extensions and capabilities when they use the Info | |||
Package, and if there are restrictions related to how UAs can use the | Package, and if there are restrictions related to how UAs can use the | |||
Info-Package together with other Info Packages. | Info-Package together with other Info Packages. | |||
As the SIP stack might not be aware of Info Package specific | As the SIP stack might not be aware of Info Package specific | |||
restrictions, it cannot be assumed that overlapping requests would be | restrictions, it cannot be assumed that overlapping requests would be | |||
rejected. As defined in Section 3.2.2, UAs will normally send a 200 | rejected. As defined in Section 4.2.2, UAs will normally send a 200 | |||
(OK) response to an INFO request. The application logic associated | (OK) response to an INFO request. The application logic associated | |||
with the Info Package needs to handle situations where UAs do not | with the Info Package needs to handle situations where UAs do not | |||
follow restrictions associated with the Info Package. | follow restrictions associated with the Info Package. | |||
10.9. Rate of INFO Requests | 10.9. Rate of INFO Requests | |||
If there is a maximum or minimum rate at which UAs can send INFO | If there is a maximum or minimum rate at which UAs can send INFO | |||
requests associated with the Info Package within a dialog, the Info | requests associated with the Info Package within a dialog, the Info | |||
Package specification MUST document the rate values. | Package specification MUST document the rate values. | |||
skipping to change at page 24, line 42 | skipping to change at page 24, line 48 | |||
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 [RFC5727] and its | and are governed by other procedures including RFC 5727 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-sensitive | 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 | |||
skipping to change at page 30, line 29 | skipping to change at page 31, 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, as described in Section 9.2, we expect this document's | requests, we expect this document's clarification of the use of INFO | |||
clarification of the use of INFO to improve the security of the | to improve the security of the Internet. Whilst rogue UAs can still | |||
Internet. Whilst rogue UAs can still send unrelated INFO requests, | send unrelated INFO requests, this mechanism provides mechanisms for | |||
this mechanism provides mechanisms for which the UAS and other | which the UAS and other security devices can associate INFO requests | |||
security devices can associate INFO requests with Info Packages that | with Info Packages that have been negotiated for a session. | |||
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 32, line 19 | skipping to change at page 33, line 19 | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | |||
with Session Description Protocol (SDP)", RFC 3264, | with Session Description Protocol (SDP)", RFC 3264, | |||
June 2002. | June 2002. | |||
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, | ||||
"Integrated Services Digital Network (ISDN) User Part | ||||
(ISUP) to Session Initiation Protocol (SIP) Mapping", | ||||
RFC 3398, December 2002. | ||||
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, | [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, | |||
"Indicating User Agent Capabilities in the Session | "Indicating User Agent Capabilities in the Session | |||
Initiation Protocol (SIP)", RFC 3840, August 2004. | Initiation Protocol (SIP)", RFC 3840, August 2004. | |||
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol | [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol | |||
for Telephones (SIP-T): Context and Architectures", | for Telephones (SIP-T): Context and Architectures", | |||
BCP 63, RFC 3372, September 2002. | BCP 63, RFC 3372, September 2002. | |||
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific | [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific | |||
Event Notification", RFC 3265, June 2002. | Event Notification", RFC 3265, June 2002. | |||
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message | ||||
Context for Internet Mail", RFC 3458, January 2003. | ||||
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., | [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., | |||
and D. Gurle, "Session Initiation Protocol (SIP) Extension | and D. Gurle, "Session Initiation Protocol (SIP) Extension | |||
for Instant Messaging", RFC 3428, December 2002. | for Instant Messaging", RFC 3428, December 2002. | |||
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network | [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network | |||
Media Services with SIP", RFC 4240, December 2005. | Media Services with SIP", RFC 4240, December 2005. | |||
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", | [RFC4960] Stewart, R., "Stream Control Transmission Protocol", | |||
RFC 4960, September 2007. | RFC 4960, September 2007. | |||
skipping to change at page 33, line 20 | 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] | |||
Porter, B., Oshry, M., Bodell, M., Rehor, K., McGlashan, | Rehor, K., Bodell, M., Burke, D., Baggia, P., Auburn, R., | |||
S., Burke, D., Auburn, R., Candell, E., Burnett, D., | Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee, | |||
Carter, J., Baggia, P., and A. Lee, "Voice Extensible | A., Porter, B., and M. Oshry, "Voice Extensible Markup | |||
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] | |||
Shanmugham, S. and D. Burnett, "Media Resource Control | Burnett, D. and S. Shanmugham, "Media Resource Control | |||
Protocol Version 2 (MRCPv2)", | Protocol Version 2 (MRCPv2)", | |||
draft-ietf-speechsc-mrcpv2-20 (work in progress), | draft-ietf-speechsc-mrcpv2-21 (work in progress), | |||
August 2009. | July 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. Acknowledgements | |||
A.1. General | ||||
This section provides examples of existing legacy INFO usages. The | ||||
section is not meant to be a comprehensive catalog of legacy INFO | ||||
usages, but it should give the reader a flavor for current legacy | ||||
INFO usages. | ||||
A.2. ISUP | ||||
[RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP | ||||
message bodies. ITU-T and 3GPP have specified similar procedures. | ||||
A.3. QSIG | ||||
[Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. | ||||
A.4. MSCML | ||||
[RFC5022] specifies how INFO is used as a transport mechanism by the | ||||
Media Server Control Markup Language (MSCML) protocol. MSCML uses an | ||||
option-tag in the Require header field to ensure that the receiver | ||||
understands the INFO content. | ||||
A.5. MSML | ||||
[RFC5707] specifies how INFO us used as a transport mechanism by the | ||||
Media Server Markup Language (MSML) protocol. | ||||
A.6. Video Fast Update | ||||
Companies have been using INFO messages in order to request fast | ||||
video update. Currently a standardized mechanism, based on RTCP, has | ||||
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 | ||||
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 | |||
Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris | Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris | |||
Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean | Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean | |||
Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon | Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon | |||
Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James | Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James | |||
Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan | Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan | |||
Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard | Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard | |||
Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael | Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael | |||
Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, | Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, | |||
Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore | Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore | |||
skipping to change at page 35, line 19 | skipping to change at page 35, line 30 | |||
Keith Drage provided comments and helped immensely with Figure 1. | Keith Drage provided comments and helped immensely with Figure 1. | |||
Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert | Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert | |||
Sparks provided valuable feedback during the WGLC process, in order | Sparks provided valuable feedback during the WGLC process, in order | |||
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 B. 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-09 | ||||
o New Motivation section added | ||||
o Old section 9 and Annex A removed | ||||
Changes from draft-ietf-sipcore-info-events-08 | Changes from draft-ietf-sipcore-info-events-08 | |||
o Further changes based on IESG comments | o Further changes based on IESG comments | |||
o Editorial changes | o Editorial changes | |||
o Section 7.3 removed | o Section 7.3 removed | |||
o New section 7.4.1.2. added, containing text from old section 7.3 | o New section 7.4.1.2. added, containing text from old section 7.3 | |||
Changes from draft-ietf-sipcore-info-events-07 | Changes from draft-ietf-sipcore-info-events-07 | |||
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 | |||
End of changes. 90 change blocks. | ||||
267 lines changed or deleted | 230 lines changed or added | |||
This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |