draft-ietf-sipcore-info-events-10.txt | rfc6086.txt | |||
---|---|---|---|---|
SIPCORE C. Holmberg | Internet Engineering Task Force (IETF) C. Holmberg | |||
Internet-Draft Ericsson | Request for Comments: 6086 Ericsson | |||
Obsoletes: 2976 (if approved) E. Burger | Obsoletes: 2976 E. Burger | |||
Intended status: Standards Track NeuStar, Inc. | Category: Standards Track Georgetown University | |||
Expires: April 15, 2011 H. Kaplan | ISSN: 2070-1721 H. Kaplan | |||
Acme Packet | Acme Packet | |||
October 12, 2010 | January 2011 | |||
Session Initiation Protocol (SIP) INFO Method and Package Framework | Session Initiation Protocol (SIP) INFO Method and Package Framework | |||
draft-ietf-sipcore-info-events-10 | ||||
Abstract | Abstract | |||
This document defines a method, INFO, for the Session Initiation | This document defines a method, INFO, for the Session Initiation | |||
Protocol (SIP), and an Info Package mechanism. The document | Protocol (SIP), and an Info Package mechanism. This document | |||
obsoletes RFC 2976. For backward compatibility the document also | obsoletes RFC 2976. For backward compatibility, this 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. | |||
Conventions Used in this Document | Status of This Memo | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in RFC 2119 [RFC2119]. | ||||
Status of this Memo | ||||
This Internet-Draft is submitted in full conformance with the | ||||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This is an Internet Standards Track document. | |||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 5741. | ||||
This Internet-Draft will expire on April 15, 2011. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc6086. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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 ....................................................3 | |||
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Conventions Used in This Document ..........................4 | |||
3. Applicability and Backward Compatibility . . . . . . . . . . . 6 | 2. Motivation ......................................................4 | |||
4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Applicability and Backward Compatibility ........................5 | |||
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. The INFO Method .................................................6 | |||
4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. General ....................................................6 | |||
4.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 7 | 4.2. INFO Request ...............................................6 | |||
4.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 8 | 4.2.1. INFO Request Sender .................................6 | |||
4.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 | 4.2.2. INFO Request Receiver ...............................7 | |||
4.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 | 4.2.3. SIP Proxies .........................................8 | |||
4.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 | 4.3. INFO Message Body ..........................................8 | |||
4.3.2. INFO Response Message Body . . . . . . . . . . . . . . 9 | 4.3.1. INFO Request Message Body ...........................8 | |||
4.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 9 | 4.3.2. INFO Response Message Body ..........................9 | |||
5. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.4. Order of Delivery ..........................................9 | |||
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 5. Info Packages ...................................................9 | |||
5.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 10 | 5.1. General ....................................................9 | |||
5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.2. User Agent Behavior .......................................10 | |||
5.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 10 | 5.2.1. General ............................................10 | |||
5.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 | 5.2.2. UA Procedures ......................................10 | |||
5.2.4. Info Package fallback rules . . . . . . . . . . . . . 12 | 5.2.3. Recv-Info Header Field Rules .......................11 | |||
5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 | 5.2.4. Info Package Fallback Rules ........................12 | |||
6. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 | 5.3. REGISTER Processing .......................................12 | |||
6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 | 6. Formal INFO Method Definition ..................................13 | |||
7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 | 6.1. INFO Method ...............................................13 | |||
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 7. INFO Header Fields .............................................15 | |||
7.2. Info-Package header field . . . . . . . . . . . . . . . . 15 | 7.1. General ...................................................15 | |||
7.3. Recv-Info header field . . . . . . . . . . . . . . . . . 16 | 7.2. Info-Package Header Field .................................15 | |||
8. Info Package Considerations . . . . . . . . . . . . . . . . . 16 | 7.3. Recv-Info Header Field ....................................16 | |||
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 8. Info Package Considerations ....................................16 | |||
8.2. Appropriateness of Info Package Usage . . . . . . . . . . 16 | 8.1. General ...................................................16 | |||
8.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 16 | 8.2. Appropriateness of Info Package Usage .....................16 | |||
8.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 17 | 8.3. INFO Request Rate and Volume ..............................16 | |||
8.4.1. Alternative SIP signaling plane mechanisms . . . . . . 17 | 8.4. Alternative Mechanisms ....................................17 | |||
8.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 18 | 8.4.1. Alternative SIP Signaling Plane Mechanisms .........17 | |||
8.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 19 | 8.4.2. Media Plane Mechanisms .............................18 | |||
8.4.3. Non-SIP-Related Mechanisms .........................19 | ||||
9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 9. Syntax .........................................................19 | |||
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 9.1. General ...................................................19 | |||
9.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 9.2. ABNF ......................................................19 | |||
10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 | 10. Info Package Requirements .....................................20 | |||
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 10.1. General ..................................................20 | |||
10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 | 10.2. Overall Description ......................................20 | |||
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 | 10.3. Applicability ............................................20 | |||
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21 | 10.4. Info Package Name ........................................21 | |||
10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 | 10.5. Info Package Parameters ..................................21 | |||
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 | 10.6. SIP Option-Tags ..........................................22 | |||
10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 22 | 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 ....................................23 | |||
10.10. Info Package Security Considerations . . . . . . . . . . 23 | 10.10. Info Package Security Considerations ....................23 | |||
10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 | 10.11. Implementation Details ..................................23 | |||
10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10.12. Examples ................................................24 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 11. IANA Considerations ...........................................24 | |||
11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 | 11.1. Update to Registration of SIP INFO Method ................24 | |||
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 ...................25 | |||
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 .......................26 | |||
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 12. Examples ......................................................26 | |||
12.1. Indication for which Info Packages UAs are willing to | 12.1. Indication of Willingness to Receive INFO Requests | |||
receive INFO requests . . . . . . . . . . . . . . . . . . 25 | for Info Packages ........................................26 | |||
12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 | 12.1.1. Initial INVITE Request ............................26 | |||
12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 | 12.1.2. Target Refresh ....................................27 | |||
12.2. INFO request associated with Info Package . . . . . . . . 27 | 12.2. INFO Request Associated with Info Package ................28 | |||
12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 | 12.2.1. Single Payload ....................................28 | |||
12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 28 | 12.2.2. Multipart INFO ....................................28 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | 13. Security Considerations .......................................30 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 14. References ....................................................31 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 32 | 14.1. Normative References .....................................31 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 32 | 14.2. Informative References ...................................32 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 | Appendix A. Acknowledgements .....................................35 | |||
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | ||||
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 that use the SIP | |||
SIP session to exchange information (which might update the state of | session to exchange information (which might update the state of | |||
those applications). | those applications). | |||
Use of the INFO method does not constitute a separate dialog usage. | Use of the INFO method does not constitute a separate dialog usage. | |||
INFO messages are always part of, and share the fate of, an invite | INFO messages are always part of, and share the fate of, an invite | |||
dialog usage [RFC5057]. INFO messages cannot be sent as part of | dialog usage [RFC5057]. INFO messages cannot be sent as part of | |||
other dialog usages, or outside an existing dialog. | other dialog usages, or outside an existing dialog. | |||
This document also defines an Info Package mechanism. An Info | This document also defines an Info Package mechanism. An Info | |||
Package specification defines the content and semantics of the | Package specification defines the content and semantics of the | |||
information carried in an INFO message associated with the Info | information carried in an INFO message associated with the Info | |||
Package. The Info Package mechanism also provides a way for UAs to | Package. The Info Package mechanism also provides a way for user | |||
indicate for which Info Packages they are willing to receive INFO | agents (UAs) to indicate for which Info Packages they are willing to | |||
requests, and which Info Package a specific INFO request is | receive INFO requests, and which Info Package a specific INFO request | |||
associated with. | is associated with. | |||
A UA uses the Recv-Info header field, on a per-dialog basis, to | A UA uses the Recv-Info header field, on a per-dialog basis, to | |||
indicate for which Info Packages it is willing to receive INFO | indicate for which Info Packages it is willing to receive INFO | |||
requests. A UA can indicate an initial set of Info Packages during | requests. A UA can indicate an initial set of Info Packages during | |||
dialog establishment and can indicate a new set during the lifetime | dialog establishment and can indicate a new set during the lifetime | |||
of the invite dialog usage. | of the invite dialog usage. | |||
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 | |||
requests for any Info-Package, but to inform other UAs that it still | INFO requests for any Info Package, while still informing other | |||
supports the Info Package mechanism. | UAs that it 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. | |||
1.1. Conventions Used in This Document | ||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in RFC 2119 [RFC2119]. | ||||
2. Motivation | 2. Motivation | |||
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 RFC 2976 [RFC2976], | the INFO method as it was previously defined in RFC 2976 [RFC2976], | |||
referred to as "legacy INFO usage". These include but are not | here referred to as "legacy INFO usage". These include but are not | |||
limited to: | limited to the following: | |||
o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part | o RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part | |||
(ISUP) in SIP message bodies. ITU-T and 3GPP have specified | (ISUP) in SIP message bodies. ITU-T and the Third Generation | |||
similar procedures. | Partnership Project (3GPP) have specified similar procedures. | |||
o [Ecma-355] specifies the encapsulation of QSIG in SIP message | ||||
o [ECMA-355] specifies the encapsulation of "QSIG" in SIP message | ||||
bodies. | bodies. | |||
o RFC 5022 [RFC5022] specifies how INFO is used as a transport | o RFC 5022 [RFC5022] specifies how INFO is used as a transport | |||
mechanism by the Media Server Control Markup Language (MSCML) | mechanism by the Media Server Control Markup Language (MSCML) | |||
protocol. MSCML uses an option-tag in the Require header field to | protocol. MSCML uses an option-tag in the Require header field to | |||
ensure that the receiver understands the INFO content. | ensure that the receiver understands the INFO content. | |||
o RFC 5707 [RFC5707] specifies how INFO us used as a transport | ||||
o RFC 5707 [RFC5707] specifies how INFO is used as a transport | ||||
mechanism by the Media Server Markup Language (MSML) protocol. | mechanism by the Media Server Markup Language (MSML) protocol. | |||
o Companies have been using INFO messages in order to request fast | o Companies have been using INFO messages in order to request fast | |||
video update. Currently a standardized mechanism, based on RTCP, | video update. Currently, a standardized mechanism, based on the | |||
has been specified in RFC 5168 [RFC5168]. | Real-time Transport Control Protocol (RTCP), has been specified in | |||
o Companies have been using INFO messages in order to transport DTMF | RFC 5168 [RFC5168]. | |||
tones. All mechanisms are proprietary, and have not been | ||||
standardized. | o Companies have been using INFO messages in order to transport | |||
Dual-Tone Multi-Frequency (DTMF) tones. All mechanisms are | ||||
proprietary and have not been standardized. | ||||
Some legacy INFO usages are also recognized as being shortcuts to | Some legacy INFO usages are also recognized as being shortcuts to | |||
more appropriate and flexible mechanisms. | more appropriate and flexible mechanisms. | |||
Furthermore, RFC 2976 did not define mechanisms that would enable a | Furthermore, RFC 2976 did not define mechanisms that would enable a | |||
SIP UA to indicate (1) the types of applications and contexts in | SIP UA to indicate (1) the types of applications and contexts in | |||
which they support the INFO method or (2) the types of application | which the UA supports the INFO method or (2) the types of | |||
and context with which a specific INFO message is associated. | applications and contexts with which a specific INFO message is | |||
associated. | ||||
Because legacy INFO usages do not have associated Info Packages, it | Because legacy INFO usages do not have associated Info Packages, it | |||
is not possible to use the Recv-Info and Info-Package header fields | 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 | 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 | 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 | 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 | field to indicate with which legacy INFO usage an INFO request is | |||
associated with. | associated. | |||
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 to indicate the types of applications and | |||
UAs support the INFO method, and the way they handle application | contexts for which the UAs support the INFO method, and the way they | |||
information transported in INFO messages. That has caused | handle application information transported in INFO messages. This | |||
interoperability problems in the industry. | has caused interoperability problems in the industry. | |||
To overcome these problems, the SIP Working Group has spent | To overcome these problems, the SIP Working Group has spent | |||
significant discussion time over many years coming to agreement on | significant discussion time over many years coming to agreement on | |||
whether it was more appropriate to fix INFO (by defining a | whether it was more appropriate to fix INFO (by defining a | |||
registration mechanism for the ways in which it was used) or to | registration mechanism for the ways in which it was used) or to | |||
deprecate it altogether (with the usage described in RFC 3398 | deprecate it altogether (with the usage described in RFC 3398 | |||
[RFC3398] being grandfathered as the sole legitimate usage). | [RFC3398] being grandfathered as the sole legitimate usage). | |||
Although it required substantial consensus building and concessions | Although it required substantial consensus building and concessions | |||
by those more inclined to completely deprecate INFO, the eventual | by those more inclined to completely deprecate INFO, the eventual | |||
direction of the working group was to publish a framework for | direction of the working group was to publish a framework for | |||
registration of INFO packages as defined in this specification. | registration of Info Packages as defined in this specification. | |||
3. Applicability and Backward Compatibility | 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. This | |||
document obsoletes RFC 2976 [RFC2976]. For backward compatibility, | document obsoletes RFC 2976 [RFC2976]. For backward compatibility, | |||
the document also specifies a "legacy" mode of usage of the INFO | this document also specifies a "legacy" mode of usage of the INFO | |||
method that is compatible with the usage previously defined in RFC | method that is compatible with the usage previously defined in | |||
2976, referred to as "legacy INFO Usage". | RFC 2976, here referred to as "legacy INFO Usage". | |||
For backward compatibility purposes, this document does not deprecate | For backward compatibility purposes, this document does not deprecate | |||
legacy INFO usages, and does not mandate users to define Info | legacy INFO usages, and does not mandate users to define Info | |||
Packages for such usages. However: | Packages for such usages. However: | |||
1. A UA MUST NOT insert an Info-Package header field in a legacy | 1. A UA MUST NOT insert an Info-Package header field in a legacy | |||
INFO request (as described in Section 3, an INFO request | INFO request (as described in Section 4.2.1, an INFO request | |||
associated with an Info Package always contains an Info-Package | associated with an Info Package always contains an Info-Package | |||
header field). | header field). | |||
2. Any new usage MUST use the Info Package mechanism defined in this | 2. Any new usage MUST use the Info Package mechanism defined in this | |||
specification, since it does not share the issues associated with | specification, since it does not share the issues associated with | |||
legacy INFO usage, and since Info Packages can be registered with | legacy INFO usage, and since Info Packages can be registered with | |||
IANA. | IANA. | |||
3. UAs are allowed to enable both legacy INFO usages and Info | 3. UAs are allowed to enable both legacy INFO usages and Info | |||
Package usages as part of the same invite dialog usage, but UAs | Package usages as part of the same invite dialog usage, but UAs | |||
SHALL NOT mix legacy INFO usages and Info Package usages in order | SHALL NOT mix legacy INFO usages and Info Package usages in order | |||
to transport the same application level information. If | to transport the same application level information. If | |||
possible, UAs SHALL prefer the usage of an Info Package. | possible, UAs SHALL prefer the usage of an Info Package. | |||
4. The INFO Method | 4. The INFO Method | |||
4.1. General | 4.1. General | |||
skipping to change at page 6, line 39 | skipping to change at page 6, line 33 | |||
Package usages as part of the same invite dialog usage, but UAs | Package usages as part of the same invite dialog usage, but UAs | |||
SHALL NOT mix legacy INFO usages and Info Package usages in order | SHALL NOT mix legacy INFO usages and Info Package usages in order | |||
to transport the same application level information. If | to transport the same application level information. If | |||
possible, UAs SHALL prefer the usage of an Info Package. | possible, UAs SHALL prefer the usage of an Info Package. | |||
4. The INFO Method | 4. The INFO Method | |||
4.1. General | 4.1. General | |||
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. | |||
A gives more details on the types of applications for which the use | Section 8 gives more details on the types of applications for which | |||
of INFO is appropriate. | the use 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. | |||
4.2. INFO Request | 4.2. INFO Request | |||
4.2.1. INFO Request Sender | 4.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 5), or associated with a legacy INFO usage (see Section 2). | 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 | |||
target refresh request within an existing invite dialog usage as | non-target refresh request within an existing invite dialog usage as | |||
described in Section 12.2 of RFC 3261. | 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 a 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 5. | 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 RFC 5057 the response represents a Transaction Only | request, based on RFC 5057 [RFC5057], the response represents a | |||
failure, and the UA MUST NOT terminate the invite dialog usage. | Transaction 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 that 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 User Agent Server (UAS) (receiver of the initial | |||
INFO request just after it has sent the response which creates the | INVITE request) sends an INFO request just after it has sent the | |||
dialog, the UAS needs to be prepared that the INFO request can reach | response that creates the dialog, the UAS needs to be prepared for | |||
the UAC before the dialog creating response, and might therefore be | the possibility that the INFO request will reach the User Agent | |||
rejected by the UAC. In addition, an INFO request might be rejected | Client (UAC) before the dialog-creating response, and might | |||
due to a race condition, if a UA sends the INFO request at the same | therefore be rejected by the UAC. In addition, an INFO request | |||
time as the remote UA sends a new set of Info Packages for which it | might be rejected due to a race condition, if a UA sends the INFO | |||
is willing to receive INFO requests. | request at the same time that the remote UA sends a new set of | |||
Info Packages for which it is willing to receive INFO requests. | ||||
4.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 4.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 | |||
error handling procedures defined in RFC 3261. | the 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 that 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 | |||
level. I.e. the application needs to trigger a new INFO request, | application level. That is, the application needs to trigger a | |||
which contains information that the previously received application | new INFO request, which contains information that the previously | |||
data was not accepted. Individual Info Package specifications need | received application data was not accepted. Individual Info | |||
to describe the details for such procedures. | Package specifications need to describe the details for such | |||
procedures. | ||||
4.2.3. SIP Proxies | 4.2.3. SIP Proxies | |||
Proxies need no additional behavior beyond that described in RFC 3261 | Proxies need no additional behavior beyond that described in RFC 3261 | |||
to support INFO. | to support INFO. | |||
4.3. INFO Message Body | 4.3. INFO Message Body | |||
4.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 | |||
Package header field parameters. | Info-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] that 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 RFC 5621. | 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 | |||
specifically associated with the INFO method and the application | not specifically associated with the INFO method and the | |||
concerned. | application 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 RFC 3261 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. | |||
4.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 that is not associated with an Info | |||
Package in an INFO response. | Package in an INFO response. | |||
4.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 [RFC3261] | |||
if an INFO request is received out of order. | to detect 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 | |||
within the application data). | numbers within the application data). | |||
5. Info Packages | 5. Info Packages | |||
5.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 with which Info Package a specific INFO request is | |||
associated with. | associated. | |||
5.2. User Agent Behavior | 5.2. User Agent Behavior | |||
5.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. | |||
5.2.2. UA Procedures | 5.2.2. UA Procedures | |||
A UA which supports the Info Package mechanism MUST indicate, using | A UA that 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 | |||
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 | |||
Info header field. This informs other UAs that the UA still supports | Recv-Info header field. This informs other UAs that the UA still | |||
the Info Package mechanism. | supports the Info Package mechanism. | |||
Example: If a UA has previously indicated Info Packages 'foo' and | Example: If a UA has previously indicated Info Packages "foo" and | |||
'bar' in a Recv-Info header field, and the UA during the lifetime of | "bar" in a Recv-Info header field, and the UA during the lifetime of | |||
the invite dialog usage wants to indicate that it does not want to | the invite dialog usage wants to indicate that it does not want to | |||
receive INFO requests for any Info Packages anymore, the UA sends a | receive INFO requests for any Info Packages anymore, the UA sends a | |||
message with an empty Recv-Info header field. | message with an empty Recv-Info header field. | |||
Once a UA has sent a message with a Recv-Info header field containing | Once a UA has sent a message with a Recv-Info header field containing | |||
a set of Info Packages, the set is valid until the UA sends a new | a set of Info Packages, the set is valid until the UA sends a new | |||
Recv-Info header field containing a new, or empty, set of Info | Recv-Info header field containing a new, or empty, set of Info | |||
Packages. | Packages. | |||
Once a UA has indicated that it is willing to receive INFO requests | Once a UA has indicated that it is willing to receive INFO requests | |||
for a specific Info Package, and a dialog has been established, the | for a specific Info Package, and a dialog has been established, the | |||
UA MUST be prepared to receive INFO request associated with that Info | UA MUST be prepared to receive INFO requests associated with that | |||
Package until the UA indicates that it is no longer willing to | Info Package until the UA indicates that it is no longer willing to | |||
receive INFO requests associated with that Info Package. | receive INFO requests associated with that Info Package. | |||
For a specific dialog usage, a UA MUST NOT send an INFO request | For a specific dialog usage, a UA MUST NOT send an INFO request | |||
associated with an Info Package until it has received an indication | associated with an Info Package until it has received an indication | |||
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 that 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 | |||
receive INFO requests the remote UA might, before it receives the | to receive INFO requests, the remote UA might, before it receives | |||
message, send an INFO request based on the old set of Info Packages. | the message, send an INFO request based on the old set of Info | |||
In this case the receiver of the INFO requests rejects, and sends a | Packages. In this case, the receiver of the INFO requests | |||
469 (Bad Info Package) response to, the INFO request. | rejects, and sends a 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 that 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 particular 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 purposes, even if a UA indicates support | |||
the Info Package mechanism, it is still allowed to enable legacy INFO | of the Info Package mechanism, it is still allowed to enable legacy | |||
usages. In addition, if a UA indicates support of the INFO method | INFO usages. In addition, if a UA indicates support of the INFO | |||
using the Allow header field [RFC3261], it does not implicitly | method 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. | |||
5.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 7.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 | o 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 | |||
willing to receive INFO requests associated with any Info Package. | not willing to receive INFO requests associated with any Info | |||
Package. | ||||
- The receiver of a request which contains a Recv-Info header field | o The receiver of a request that 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 | |||
to the request, even if the request contains an empty Recv-Info | response to the request, even if the request contains an empty | |||
header field, and even if the header field value of the receiver has | Recv-Info header field, and even if the header field value of the | |||
not changed since the previous time it sent a Recv-Info header field. | receiver has not changed since the previous time it sent a | |||
Recv-Info header field. | ||||
- A UA MUST NOT include a Recv-Info header field in a response if the | o A UA MUST NOT include a Recv-Info header field in a response if | |||
associated request did not contain a Recv-Info header field. | the associated request did not contain a Recv-Info header field. | |||
NOTE: Different from the rules for generating SDP answers [RFC3264], | NOTE: In contrast to the rules for generating Session Description | |||
the receiver of a request which contains a set of Info Packages is | Protocol (SDP) answers [RFC3264], the receiver of a request is not | |||
not restricted to generate its own set of Info Packages as a subset | restricted to generating 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 | |||
the request. | of the request. | |||
Similar to SDP answers, the receiver can include the same Recv-Info | As with 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. | |||
5.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 that 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 that 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 | |||
from the rules for other types of dialog state information (SDP, | differ from the rules for other types of dialog state information | |||
target, etc). | (SDP, target, etc.). | |||
5.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 particular 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 RFC 3840 [RFC3840]. However, this document | mechanisms, e.g., based on RFC 3840 [RFC3840]. However, this | |||
does not define a feature tag for the Info Package mechanism, or a | document does not define a feature tag for the Info Package | |||
mechanism to define feature tags for specific Info Packages. | mechanism, or a mechanism to define feature tags for specific Info | |||
Packages. | ||||
6. Formal INFO Method Definition | 6. Formal INFO Method Definition | |||
6.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 RFC 2976 | replaces the definition and registrations found in RFC 2976 | |||
[RFC2976]. | [RFC2976]. | |||
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. | This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. | |||
Header Where INFO | Header field 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 | |||
Accept-Language 415 o | Accept-Language 415 o | |||
Accept-Resource-Priority 2xx,417 o | Accept-Resource-Priority 2xx,417 o | |||
Alert-Info - | Alert-Info - | |||
Allow R o | Allow R o | |||
Allow 405 m | Allow 405 m | |||
Allow r o | Allow r o | |||
Authentication-Info 2xx o | Authentication-Info 2xx o | |||
Authorization R o | Authorization R o | |||
Call-ID c m | Call-ID c m | |||
Call-Info o | Call-Info o | |||
Contact - | Contact - | |||
Content-Disposition o | Content-Disposition o | |||
Content-Encoding o | Content-Encoding o | |||
Content-Language o | Content-Language o | |||
Content-Length o | Content-Length o | |||
Content-Type * | Content-Type * | |||
CSeq c m | CSeq c m | |||
Date o | Date o | |||
Error-Info 3xx-6xx o | Error-Info 3xx-6xx o | |||
Expires - | Expires - | |||
From c m | From c m | |||
Geolocation R o | Geolocation R o | |||
Geolocation-Error r o | Geolocation-Error r o | |||
Max-Breadth R - | Max-Breadth R - | |||
Max-Forwards R o | Max-Forwards R o | |||
MIME-Version o | MIME-Version o | |||
Min-Expires - | Min-Expires - | |||
Organization - | Organization - | |||
Priority R - | Priority R - | |||
Privacy o | Privacy o | |||
Proxy-Authenticate 401 o | Proxy-Authenticate 401 o | |||
Proxy-Authenticate 407 m | Proxy-Authenticate 407 m | |||
Proxy-Authorization R o | Proxy-Authorization R o | |||
Proxy-Require R o | Proxy-Require R o | |||
Reason R o | Reason R o | |||
Record-Route R o | Record-Route R o | |||
Record-Route 2xx,18x o | Record-Route 2xx,18x o | |||
Referred-By R o | Referred-By R o | |||
Request-Disposition R o | Request-Disposition R o | |||
Require o | Require o | |||
Resource-Priority o | Resource-Priority o | |||
Retry-After R - | Retry-After R - | |||
Retry-After 404,413,480,486 o | Retry-After 404,413,480,486 o | |||
Retry-After 500,503 o | Retry-After 500,503 o | |||
Retry-After 600,603 o | Retry-After 600,603 o | |||
Route R o | Route R o | |||
Security-Client R o | Security-Client R o | |||
Security-Server 421,494 o | Security-Server 421,494 o | |||
Security-Verify R o | Security-Verify R o | |||
Server r o | Server r o | |||
Subject R o | Subject R o | |||
Supported R o | Supported R o | |||
Supported 2xx o | Supported 2xx o | |||
Timestamp o | Timestamp o | |||
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 | Table 1: Summary of Header Fields | |||
7. INFO Header Fields | 7. INFO Header Fields | |||
7.1. General | 7.1. General | |||
This table expands on tables 2 and 3 in RFC 3261 [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 | |||
Header field where SUB NOT RFR | Header field where SUB NOT RFR | |||
-------------------------------- | -------------------------------- | |||
Info-Package R - - - | Info-Package R - - - | |||
Recv-Info R - - - | Recv-Info R - - - | |||
Recv-Info 2xx - - - | Recv-Info 2xx - - - | |||
Recv-Info 1xx - - - | Recv-Info 1xx - - - | |||
Recv-Info 469 - - - | Recv-Info 469 - - - | |||
Recv-Info r - - - | Recv-Info r - - - | |||
Table 2: INFO-related Header Fields | Table 2: INFO-Related Header Fields | |||
The support and usage of the Info-Package and Recv-Info header fields | The support and usage of the Info-Package and Recv-Info header fields | |||
is not applicable to UAs that only support legacy INFO usages. | are not applicable to UAs that only support legacy INFO usages. | |||
* 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 | |||
to the INVITE request, if the associated INVITE request contained | the INVITE request, if the associated INVITE request contained a | |||
a Recv-Info header field. | Recv-Info header field. | |||
*** Mandatory if the associated request contained a Recv-Info | *** Mandatory if the associated request contained a Recv-Info header | |||
header field. | field. | |||
As defined in section 20 of RFC 3261, a "mandatory" header field | As defined in Section 20 of RFC 3261, a "mandatory" header field MUST | |||
MUST be present in a request, and MUST be understood by the UAS | be present in a request, and MUST be understood by the UAS receiving | |||
receiving the request." | the request. | |||
7.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 4 | "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 | |||
Info with those in the Info-Package header field value, one compares | Recv-Info with those in the Info-Package header field value, one | |||
the Info-package-name portion of the Info-package-type portion of the | compares the Info-package-name portion of the Info-package-type | |||
Info-Package header field octet-by-octet with that of the Recv-Info | portion of the Info-Package header field octet by octet with that of | |||
header field value. That is, the Info Package name is case | the Recv-Info header field value. That is, the Info Package name is | |||
sensitive. Info-package-param is not part of the comparison-checking | case sensitive. Info-package-param is not part of the comparison- | |||
algorithm. | checking 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. | |||
7.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 5 | "message-header" in the SIP message grammar [RFC3261]. Section 5 | |||
describes the Recv-Info header field usage. | describes the Recv-Info header field usage. | |||
8. Info Package Considerations | 8. Info Package Considerations | |||
8.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. | application information for a specific use-case. | |||
8.2. Appropriateness of Info Package Usage | 8.2. Appropriateness of Info Package Usage | |||
When designing an Info Package, for application level information | When designing an Info Package, for application level information | |||
exchange, it is important to consider: is signaling, using INFO | exchange, it is important to consider: is signaling, using INFO | |||
requests, within a SIP dialog, an appropriate mechanism for the use- | requests, within a SIP dialog, an appropriate mechanism for the use- | |||
case? Is it because it is the most reasonable and appropriate | case? Is it because it is the most reasonable and appropriate | |||
choice, or merely because "it's easy"? Choosing an inappropriate | choice, or merely because "it's easy"? Choosing an inappropriate | |||
mechanism for a specific use-case can cause negative effects in SIP | mechanism for a specific use-case can cause negative effects in SIP | |||
networks where the mechanism is used. | networks where the mechanism is used. | |||
8.3. INFO Request Rate and Volume | 8.3. 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 INFO | |||
message is directly determined by the application. This can cause | messages are 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 | |||
exchanged during the lifetime a normal SIP session is rather small. | exchanged during the lifetime of a normal SIP session is rather | |||
small. | ||||
Some applications, like sending of Dual-Tone Multi-Frequency (DTMF) | Some applications, like those sending Dual-Tone Multi-Frequency | |||
tones, can generate a burst of up to 20 messages per second. Other | (DTMF) tones, can generate a burst of up to 20 messages per second. | |||
applications, like constant GPS location updates, could generate a | Other applications, like constant GPS location updates, could | |||
high rate of INFO requests during the lifetime of the invite dialog | generate a high rate of INFO requests during the lifetime of the | |||
usage. | invite dialog usage. | |||
A designer of an Info Package, and the application that uses it, need | 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 | 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 | messages have on the network and on other traffic, since it normally | |||
cannot be ensured that INFO messages will be carried over a | cannot be ensured that INFO messages will be carried over a | |||
congestion-controlled transport protocol end-to-end. Even if an INFO | congestion-controlled transport protocol end-to-end. Even if an INFO | |||
message is sent over such a transport protocol, a downstream SIP | message is sent over such a transport protocol, a downstream SIP | |||
entity might forward the message over a transport protocol that does | entity might forward the message over a transport protocol that does | |||
not provide congestion control. | not provide congestion control. | |||
skipping to change at page 17, line 29 | skipping to change at page 17, line 34 | |||
Appropriate mechanisms for such traffic include the Hypertext | Appropriate mechanisms for such traffic include the Hypertext | |||
Transfer Protocol (HTTP) [RFC2616], the Message Session Relay | Transfer Protocol (HTTP) [RFC2616], the Message Session Relay | |||
Protocol (MSRP) [RFC4975], or other media plane data transport | Protocol (MSRP) [RFC4975], or other media plane data transport | |||
mechanisms. | mechanisms. | |||
RFC 5405 [RFC5405] provides additional guidelines for applications | RFC 5405 [RFC5405] provides additional guidelines for applications | |||
using UDP that may be useful background reading. | using UDP that may be useful background reading. | |||
8.4. Alternative Mechanisms | 8.4. Alternative Mechanisms | |||
8.4.1. Alternative SIP signaling plane mechanisms | 8.4.1. Alternative SIP Signaling Plane Mechanisms | |||
8.4.1.1. General | 8.4.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. | |||
8.4.1.2. SUBSCRIBE/NOTIFY | 8.4.1.2. SUBSCRIBE/NOTIFY | |||
An alternative for application level interaction is to use | An alternative for application level interaction is to use | |||
subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and | subscription-based events [RFC3265] that use 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 keypad 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 | |||
exchange using invite dialog usages [RFC5057]. | exchange using invite dialog usages [RFC5057]. | |||
While an INFO request is always part of, and shares the fate of, an | While an INFO request is always part of, and shares the fate of, an | |||
existing invite dialog usage, a SUBSCRIBE request creates a separate | existing invite dialog usage, a SUBSCRIBE request creates a separate | |||
dialog usage [RFC5057], and is normally sent outside an existing | dialog usage [RFC5057], and is normally sent outside an existing | |||
dialog usage. | dialog usage. | |||
The subscription-based mechanism can be used by SIP entities to | The subscription-based mechanism can be used by SIP entities to | |||
receive state information about SIP dialogs and sessions, without | receive state information about SIP dialogs and sessions, without | |||
requiring the entities to be part of the route set of those dialogs | requiring the entities to be part of the route set of those dialogs | |||
and sessions. | and sessions. | |||
As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies | As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies | |||
and B2BUAs, the resource impact caused by the subscription dialogs | and back-to-back user agents (B2BUAs), the resource impact caused by | |||
needs to be considered. The number of subscription dialogs per user | the subscription dialogs needs to be considered. The number of | |||
also needs to be considered. | subscription dialogs per user 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 that are part of the | |||
dialog route set, but do not have any interest in the application | dialog route set, but do not have any interest in the application | |||
information transported between the end users. | information transported between the end users. | |||
8.4.1.3. MESSAGE | 8.4.1.3. MESSAGE | |||
The MESSAGE method [RFC3428] defines one-time instant message | The MESSAGE method [RFC3428] defines one-time instant message | |||
exchange, typically for sending MIME contents for rendering to the | exchange, typically for sending MIME contents for rendering to the | |||
user. | user. | |||
8.4.2. Media Plane Mechanisms | 8.4.2. Media Plane Mechanisms | |||
8.4.2.1. General | 8.4.2.1. General | |||
In SIP, media plane channels associated with SIP dialogs are | In SIP, media plane channels associated with SIP dialogs are | |||
established using SIP signaling, but the data exchanged on the media | established using SIP signaling, but the data exchanged on the media | |||
plane channel does not traverse SIP signaling intermediates, so if | plane channel does not traverse SIP signaling intermediates, so if | |||
there will be a lot of information exchanged, and there is no need | there will be a lot of information exchanged, and there is no need | |||
for the SIP signaling intermediaries to examine the information, it | for the SIP signaling intermediaries to examine the information, it | |||
is recommended to use a media plane mechanism, rather than a SIP | is recommended to use a media plane mechanism, rather than a SIP- | |||
signaling based. | signaling-based mechanism. | |||
A low latency requirement for the exchange of information is one | A low-latency requirement for the exchange of information is one | |||
strong indicator for using a media channel. Exchanging information | strong indicator for using a media channel. Exchanging information | |||
through the SIP routing network can introduce hundreds of | through the SIP routing network can introduce hundreds of | |||
milliseconds of latency. | milliseconds of latency. | |||
8.4.2.2. MRCP | 8.4.2.2. MRCP | |||
One mechanism for media plane exchange of application data is the | One mechanism for media plane exchange of application data is the | |||
Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2], | Media Resource Control Protocol (MRCP) [SPEECHSC-MRCPv2], where a | |||
where a media plane connection-oriented channel, such as a | media plane connection-oriented channel, such as a Transmission | |||
Transmission Control Protocol (TCP) [RFC0793] or Stream Control | Control Protocol (TCP) [RFC0793] or Stream Control Transmission | |||
Transmission Protocol (SCTP) [RFC4960] stream is established. | Protocol (SCTP) [RFC4960] stream is established. | |||
8.4.2.3. MRSP | 8.4.2.3. MSRP | |||
MSRP [RFC4975] defines session-based instant messaging as well as | MSRP [RFC4975] defines session-based instant messaging as well as | |||
bulk file transfer and other such large-volume uses. | bulk file transfer and other such large-volume uses. | |||
8.4.3. Non-SIP related mechanisms | 8.4.3. Non-SIP-Related Mechanisms | |||
Another alternative is to use a SIP-independent mechanism, such as | Another alternative is to use a SIP-independent mechanism, such as | |||
HTTP [RFC2616]. In this model, the UA knows about a rendezvous point | HTTP [RFC2616]. In this model, the UA knows about a rendezvous point | |||
to direct HTTP requests to for the transfer of information. Examples | to which it can direct HTTP requests for the transfer of information. | |||
include encoding of a prompt to retrieve in the SIP Request URI in | Examples include encoding of a prompt to retrieve in the SIP Request | |||
[RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- | URI [RFC4240] or the encoding of a SUBMIT target in a VoiceXML | |||
voicexml21-20070619] script. | [W3C.REC-voicexml21-20070619] script. | |||
9. Syntax | 9. Syntax | |||
9.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 RFC 3261 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 RFC 5234 [RFC5234]. | specification is conformant to RFC 5234 [RFC5234]. | |||
9.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 | |||
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 | |||
Package specifications to repeat procedures defined in this document, | Package specifications to repeat procedures defined in this document, | |||
unless needed for clarification or emphasis purpose. | unless needed for purposes of clarification or emphasis. | |||
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 Package | |||
Packages specifications MAY strengthen "SHOULD", "MAY", or | specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" | |||
"RECOMMENDED" requirements to "MUST" strength if applications | requirements to "MUST" if applications associated with the Info | |||
associated with the Info Package require it. | 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 to | |||
the specific Info Package. | the specific Info Package. | |||
Section 8.4 describes alternative mechanisms, which should be | Section 8.4 describes alternative mechanisms, which should be | |||
considered as part of the process for solving a specific use-case, | considered as part of the process for solving a specific use-case, | |||
when there is a need for transporting application information. | when there is a need for transporting application information. | |||
10.2. Overall Description | 10.2. Overall Description | |||
The Info Package specification MUST contain an overall description of | The Info Package specification MUST contain an overall description of | |||
the Info Package: what type of information are carried in INFO | the Info Package: what type of information is carried in INFO | |||
requests associated with the Info Package, and for what type of | requests associated with the Info Package, and for what types of | |||
applications and functionalities UAs can use the Info Package. | applications and functionalities UAs can use the Info Package. | |||
If the Info Package is defined for a specific application, the Info | If the Info Package is defined for a specific application, the Info | |||
Package specification MUST state which application UAs can use the | Package specification MUST state which application UAs can use the | |||
Info Package with. | Info Package with. | |||
10.3. Applicability | 10.3. Applicability | |||
The Info Package specification MUST describe why the Info Package | The Info Package specification MUST describe why the Info Package | |||
mechanism, rather than some other mechanism, has been chosen for the | mechanism, rather than some other mechanism, has been chosen for the | |||
specific use-case to transfer application information between SIP | specific use-case to transfer application information between SIP | |||
endpoints. Common reasons can be a requirement for SIP Proxies or | endpoints. Common reasons can be a requirement for SIP proxies or | |||
back-to-back user agents (B2BUAs) to see the transported application | back-to-back user agents (B2BUAs) to see the transported application | |||
information (which would not be the case if the information was | information (which would not be the case if the information was | |||
transported on a media path), or that it is not seen feasible to | transported on a media path), or that it is not seen as feasible to | |||
establish separate dialogs (subscription) in order to transport the | establish separate dialogs (subscription) in order to transport the | |||
information. | information. | |||
Annex A provides more information, and describes alternative | Section 8 provides more information and describes alternative | |||
mechanisms which one should consider for solving a specific use-case. | mechanisms that 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 9.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 a 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 | |||
foo_v2), the Info Package mechanism does not distinguish a version | (e.g., foo_v2), the Info Package mechanism does not distinguish a | |||
number from the rest of the Info Package name. | version number from the rest of the Info Package name. | |||
10.5. Info Package Parameters | 10.5. Info Package Parameters | |||
The Info Package specification MAY define Info Package parameters, | The Info Package specification MAY define Info Package parameters, | |||
which can be used in the Recv-Info or Info-Package header fields, | which can be used in the Recv-Info or Info-Package header fields, | |||
together with the header field value which indicates the Info Package | together with the header field value that indicates the Info Package | |||
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 applicable to only the | |||
Info header field, the Info-Package header field, or both. | Recv-Info header field, only the Info-Package header field, or to | |||
both. | ||||
By default, an Info Package parameter is only applicable for the Info | By default, an Info Package parameter is only applicable to the Info | |||
Package for which the parameter has been explicitly defined. | Package for which the parameter has been explicitly defined. | |||
Info Package parameters defined for specific Info Packages can share | Info Package parameters defined for specific Info Packages can share | |||
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 RFC 3261. | be used as described in RFC 3261. | |||
The registration requirements for option tags are defined in RFC 5727 | 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, including the syntax, semantics, | |||
semantics and MIME type of the each body part, or refer to other | and MIME type of each body part, or refer to other documents that | |||
documents which define the body parts. | 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 | |||
Package, the Info Package specification MUST define whether UAs need | Package, the Info Package specification MUST define whether UAs need | |||
to use multipart body parts in order to include multiple body parts | to use multipart body parts, in order to include multiple body parts | |||
in a single INFO request. | in a single INFO request. | |||
10.8. Info Package Usage Restrictions | 10.8. Info Package Usage Restrictions | |||
If there are restrictions on how UAs can use an Info Package, the | If there are restrictions on how UAs can use an Info Package, the | |||
Info Package specification MUST document such restrictions. | Info Package specification MUST document such restrictions. | |||
There can be restrictions related to whether UAs are allowed to send | There can be restrictions related to whether UAs are allowed to send | |||
overlapping (outstanding) INFO requests associated with the Info | overlapping (outstanding) INFO requests associated with the Info | |||
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 4.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. | |||
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 a 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, this | |||
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 Transport | |||
to secure the Info Package payload, since intermediaries will have | Layer Security (TLS) [RFC5246] in order to secure the Info Package | |||
access to the payload, and beyond the first hop, there is no way to | payload, since intermediaries will have access to the payload, and | |||
assure subsequent hops will not forwards the payload in clear text. | because beyond the first hop, there is no way to assure subsequent | |||
The best way to ensure secure transport at the application level is | hops will not forward the payload in clear text. The best way to | |||
to have the security at the application level. One way of achieving | ensure secure transport at the application level is to have the | |||
this is to use end-to-end security techniques such as S/MIME | security at the application level. One way of achieving this is | |||
[RFC5751]. | to use end-to-end security techniques such as Secure/Multipurpose | |||
Internet Mail Extensions (S/MIME) [RFC5751]. | ||||
10.11. Implementation Details | 10.11. Implementation Details | |||
It is strongly RECOMMENDED that the Info Package specification | It is strongly RECOMMENDED that the Info Package specification define | |||
defines the procedure how implementors shall implement and use the | the procedure regarding how implementors shall implement and use the | |||
Info Package, or refer to other locations where implementors can find | Info Package, or refer to other locations where implementors can find | |||
that information. | that information. | |||
NOTE: Sometimes Info Package designer might choose to not reveal the | NOTE: Sometimes an Info Package designer might choose to not | |||
details of an Info Package. However, in order to allow multiple | reveal the details of an Info Package. However, in order to allow | |||
implementations to support the Info Package, Info Package designers | multiple implementations to support the Info Package, Info Package | |||
are strongly encouraged to provide the implementation details. | designers are strongly encouraged to provide the implementation | |||
details. | ||||
10.12. Examples | 10.12. Examples | |||
It is RECOMMENDED that the Info Package specification provides | It is RECOMMENDED that the Info Package specification provide | |||
demonstrative message flow diagrams, paired with complete messages | demonstrative message flow diagrams, paired with complete messages | |||
and message descriptions. | and message descriptions. | |||
Note that example flows are by definition informative, and do not | Note that example flows are by definition informative, and do not | |||
replace normative text. | replace normative text. | |||
11. IANA Considerations | 11. IANA Considerations | |||
11.1. Update to Registration of SIP INFO Method | 11.1. Update to Registration of SIP INFO Method | |||
Please update the existing registration in the SIP Methods and | IANA updated the existing registration in the "Methods and Response | |||
Response Codes registry under the SIP Parameters registry that | Codes" registry under "Session Initiation Protocol (SIP) Parameters" | |||
states: | from: | |||
Method: INFO | Method: INFO | |||
Reference: [RFC2976] | Reference: [RFC2976] | |||
to: | to: | |||
Method: INFO | Method: INFO | |||
Reference: [RFCXXXX] | Reference: [RFC6086] | |||
11.2. Registration of the Info-Package header field | 11.2. Registration of the Info-Package Header Field | |||
Please add the following new SIP header field in the Header Fields | IANA added the following new SIP header field in the "Header Fields" | |||
subregistry under the SIP Parameters registry. | registry under "Session Initiation Protocol (SIP) Parameters". | |||
Header Name: Info-Package | Header Name: Info-Package | |||
Compact Form: (none) | Compact Form: (none) | |||
Reference: [RFCXXXX] | Reference: [RFC6086] | |||
11.3. Registration of the Recv-Info header field | 11.3. Registration of the Recv-Info Header Field | |||
Please add the following new SIP header field in the Header Fields | IANA added the following new SIP header field in the "Header Fields" | |||
subregistry under the SIP Parameters registry. | registry under "Session Initiation Protocol (SIP) Parameters". | |||
Header Name: Recv-Info | Header Name: Recv-Info | |||
Compact Form: (none) | Compact Form: (none) | |||
Reference: [RFCXXXX] | Reference: [RFC6086] | |||
11.4. Creation of the Info Packages Registry | 11.4. Creation of the Info Packages Registry | |||
Please create a subregistry in the SIP Parameters registry for Info | IANA created the following registry under "Session Initiation | |||
Packages. | Protocol (SIP) Parameters": | |||
Note to the reviewer: | Info Packages | |||
The policy for review of Info Packages is "Specification Required", | Note to the reviewer: | |||
as defined in [RFC5226]. This policy was selected because Info | ||||
Packages re-use an existing mechanism for transport of arbitrary | ||||
session-associated data within SIP, and therefore new Info Packages | ||||
do not require the more extensive review required by specifications | ||||
that make fundamental protocol changes. However, the reviewer is | ||||
expected to verify that each Info Package registration is in fact | ||||
consistent with this definition. Changes to the SIP protocol and | ||||
state machine are outside of the allowable scope for an Info Package | ||||
and are governed by other procedures including RFC 5727 and its | ||||
successors, if any. | ||||
The following data elements populate the Info Package Registry. | The policy for review of Info Packages is "Specification | |||
Required", as defined in [RFC5226]. This policy was selected | ||||
because Info Packages re-use an existing mechanism for transport | ||||
of arbitrary session-associated data within SIP; therefore, new | ||||
Info Packages do not require the more extensive review required by | ||||
specifications that make fundamental protocol changes. However, | ||||
the reviewer is expected to verify that each Info Package | ||||
registration is in fact consistent with this definition. Changes | ||||
to the SIP protocol and state machine are outside of the allowable | ||||
scope for an Info Package and are governed by other procedures | ||||
including RFC 5727 and its successors, if any. | ||||
The following data elements populate the Info Packages 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 that 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 | |||
Please add the following new header field value to the Content- | IANA added the following new header field value to the "Mail Content | |||
Disposition registry. | Disposition Values" registry under "Mail Content Disposition Values | |||
and Parameters". | ||||
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: RFC6086 | |||
11.6. SIP Response Code 469 Registration | 11.6. SIP Response Code 469 Registration | |||
Please register the following new response code in the Session | IANA registered the following new response code in the "Session | |||
Initiation Protocol Parameters - Response Codes registry. | Initiation Protocol (SIP) 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: RFC6086 | |||
12. Examples | 12. Examples | |||
12.1. Indication for which Info Packages UAs are willing to receive | 12.1. Indication of Willingness to Receive INFO Requests for Info | |||
INFO requests | Packages | |||
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 | |||
it is willing to receive INFO requests for Info Packages P and R. | it is willing to receive INFO requests for Info Packages P and R. | |||
INVITE sip:bob@example.com SIP/2.0 | INVITE sip:bob@example.com SIP/2.0 | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 | Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 | |||
Max-Forwards: 70 | Max-Forwards: 70 | |||
To: Bob <sip:bob@example.com> | To: Bob <sip:bob@example.com> | |||
From: Alice <sip:alice@example.com>;tag=1928301774 | From: Alice <sip:alice@example.com>;tag=1928301774 | |||
Call-ID: a84b4c76e66710@pc33.example.com | Call-ID: a84b4c76e66710@pc33.example.com | |||
skipping to change at page 26, line 22 | skipping to change at page 27, line 8 | |||
Recv-Info: P, R | Recv-Info: P, R | |||
Contact: <sip:alice@pc33.example.com> | Contact: <sip:alice@pc33.example.com> | |||
Content-Type: application/sdp | Content-Type: application/sdp | |||
Content-Length: ... | Content-Length: ... | |||
... | ... | |||
The UAS sends a 200 (OK) response back to the UAC, where the UAS | The UAS sends a 200 (OK) response back to the UAC, where the UAS | |||
indicates that it is willing to receive INFO requests for Info | indicates that it is willing to receive INFO requests for Info | |||
Packages R and T. | Packages R and T. | |||
SIP/2.0 200 OK | ||||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 | ||||
To: Bob <sip:bob@example.com>;tag=a6c85cf | ||||
From: Alice <sip:alice@example.com>;tag=1928301774 | ||||
Call-ID: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314159 INVITE | ||||
Contact: <sip:bob@pc33.example.com> | ||||
Recv-Info: R, T | ||||
Content-Type: application/sdp | ||||
Content-Length: ... | ||||
... | SIP/2.0 200 OK | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776; | ||||
received=192.0.2.1 | ||||
To: Bob <sip:bob@example.com>;tag=a6c85cf | ||||
From: Alice <sip:alice@example.com>;tag=1928301774 | ||||
Call-ID: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314159 INVITE | ||||
Contact: <sip:bob@pc33.example.com> | ||||
Recv-Info: R, T | ||||
Content-Type: application/sdp | ||||
Content-Length: ... | ||||
... | ||||
The UAC sends an ACK request. | The UAC sends an ACK request. | |||
ACK sip:bob@pc33.example.com SIP/2.0 | ACK sip:bob@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 | Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 | |||
Max-Forwards: 70 | Max-Forwards: 70 | |||
To: Bob <sip:bob@example.com>;tag=a6c85cf | To: Bob <sip:bob@example.com>;tag=a6c85cf | |||
From: Alice <sip:alice@example.com>;tag=1928301774 | From: Alice <sip:alice@example.com>;tag=1928301774 | |||
Call-ID: a84b4c76e66710@pc33.example.com | Call-ID: a84b4c76e66710@pc33.example.com | |||
CSeq: 314159 ACK | CSeq: 314159 ACK | |||
Content-Length: 0 | Content-Length: 0 | |||
12.1.2. Target refresh | 12.1.2. Target Refresh | |||
The UAC sends an UPDATE request within the invite dialog usage, where | The UAC sends an UPDATE request within the invite dialog usage, where | |||
the UAC indicates (using an empty Recv-Info header field) that it is | the UAC indicates (using an empty Recv-Info header field) that it is | |||
not willing to receive INFO requests for any Info Packages. | not willing to receive INFO requests for any Info Packages. | |||
UPDATE sip:bob@pc33.example.com SIP/2.0 | UPDATE sip:bob@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 | Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 | |||
Max-Forwards: 70 | Max-Forwards: 70 | |||
To: Bob <sip:bob@example.com>;tag=a6c85cf | To: Bob <sip:bob@example.com>;tag=a6c85cf | |||
From: Alice <sip:alice@example.com>;tag=1928301774 | From: Alice <sip:alice@example.com>;tag=1928301774 | |||
skipping to change at page 27, line 21 | skipping to change at page 28, line 7 | |||
CSeq: 314163 UPDATE | CSeq: 314163 UPDATE | |||
Recv-Info: | Recv-Info: | |||
Contact: <sip:alice@pc33.example.com> | Contact: <sip:alice@pc33.example.com> | |||
Content-Type: application/sdp | Content-Type: application/sdp | |||
Content-Length: ... | Content-Length: ... | |||
... | ... | |||
The UAS sends a 200 (OK) response back to the UAC, where the UAS | The UAS sends a 200 (OK) response back to the UAC, where the UAS | |||
indicates that it is willing to receive INFO requests for Info | indicates that it is willing to receive INFO requests for Info | |||
Packages R, T. | Packages R and T. | |||
SIP/2.0 200 OK | ||||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 | ||||
To: Bob <sip:bob@example.com>;tag=a6c85cf | ||||
From: Alice <sip:alice@example.com>;tag=1928301774 | ||||
Call-ID: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314163 INVITE | ||||
Contact: <sip:alice@pc33.example.com> | ||||
Recv-Info: R, T | ||||
Content-Type: application/sdp | ||||
Content-Length: ... | ||||
... | SIP/2.0 200 OK | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893; | ||||
received=192.0.2.1 | ||||
To: Bob <sip:bob@example.com>;tag=a6c85cf | ||||
From: Alice <sip:alice@example.com>;tag=1928301774 | ||||
Call-ID: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314163 INVITE | ||||
Contact: <sip:alice@pc33.example.com> | ||||
Recv-Info: R, T | ||||
Content-Type: application/sdp | ||||
Content-Length: ... | ||||
12.2. INFO request associated with Info Package | ... | |||
12.2.1. Single payload | 12.2. INFO Request Associated with Info Package | |||
The UA sends an INFO request associated with Info Package foo. | 12.2.1. Single Payload | |||
The UA sends an INFO request associated with Info Package "foo". | ||||
INFO sip:alice@pc33.example.com SIP/2.0 | INFO sip:alice@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | |||
To: Bob <sip:bob@example.com>;tag=a6c85cf | To: Bob <sip:bob@example.com>;tag=a6c85cf | |||
From: Alice <sip:alice@example.com>;tag=1928301774 | From: Alice <sip:alice@example.com>;tag=1928301774 | |||
Call-Id: a84b4c76e66710@pc33.example.com | Call-Id: a84b4c76e66710@pc33.example.com | |||
CSeq: 314333 INFO | CSeq: 314333 INFO | |||
Info-Package: foo | Info-Package: foo | |||
Content-type: application/foo | Content-type: application/foo | |||
Content-Disposition: Info-Package | Content-Disposition: Info-Package | |||
Content-length: 24 | Content-length: 24 | |||
I am a foo message type | I am a foo message type | |||
12.2.2. Multipart INFO | 12.2.2. Multipart INFO | |||
12.2.2.1. Non-Info Package body part | 12.2.2.1. Non-Info Package Body Part | |||
SIP extensions can sometimes add body part payloads into an INFO | SIP extensions can sometimes add body part payloads into an INFO | |||
request, independent of the Info Package. In this case, the Info | request, independent of the Info Package. In this case, the Info | |||
Package payload gets put into a Multipart MIME body, with a Content- | Package payload gets put into a multipart MIME body, with a | |||
Disposition header field that indicates which body part is associated | Content-Disposition header field that indicates which body part is | |||
with the Info Package. | associated with the Info Package. | |||
INFO sip:alice@pc33.example.com SIP/2.0 | INFO sip:alice@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | |||
To: Alice <sip:alice@example.net>;tag=1234567 | To: Alice <sip:alice@example.net>;tag=1234567 | |||
From: Bob <sip:bob@example.com>;tag=abcdefg | From: Bob <sip:bob@example.com>;tag=abcdefg | |||
Call-Id: a84b4c76e66710@pc33.example.com | Call-Id: a84b4c76e66710@pc33.example.com | |||
CSeq: 314400 INFO | CSeq: 314400 INFO | |||
Info-Package: foo | Info-Package: foo | |||
Content-Type: multipart/mixed;boundary="theboundary" | Content-Type: multipart/mixed;boundary="theboundary" | |||
Content-Length: ... | Content-Length: ... | |||
skipping to change at page 29, line 29 | skipping to change at page 29, line 29 | |||
<mumble stuff> | <mumble stuff> | |||
--theboundary | --theboundary | |||
Content-Type: application/foo-x | Content-Type: application/foo-x | |||
Content-Disposition: Info-Package | Content-Disposition: Info-Package | |||
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-- | |||
12.2.2.2. Info Package with multiple body parts inside multipart body | 12.2.2.2. Info Package with Multiple Body Parts inside Multipart Body | |||
part | Part | |||
Multiple body part payloads can be associated with a single Info | Multiple body part payloads can be associated with a single Info | |||
Package. In this case, the body parts are put into a Multipart MIME | Package. In this case, the body parts are put into a multipart MIME | |||
body, with a Content-Disposition header field that indicates which | body, with a Content-Disposition header field that indicates which | |||
body part is associated with the Info Package. | body part is associated with the Info Package. | |||
INFO sip:alice@pc33.example.com SIP/2.0 | INFO sip:alice@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | |||
To: Alice <sip:alice@example.net>;tag=1234567 | To: Alice <sip:alice@example.net>;tag=1234567 | |||
From: Bob <sip:bob@example.com>;tag=abcdefg | From: Bob <sip:bob@example.com>;tag=abcdefg | |||
Call-Id: a84b4c76e66710@pc33.example.com | Call-Id: a84b4c76e66710@pc33.example.com | |||
CSeq: 314423 INFO | CSeq: 314423 INFO | |||
Info-Package: foo | Info-Package: foo | |||
skipping to change at page 30, line 31 | skipping to change at page 30, line 15 | |||
<mumble stuff> | <mumble stuff> | |||
--theboundary | --theboundary | |||
Content-Type: application/foo-y | Content-Type: application/foo-y | |||
Content-length: 59 | Content-length: 59 | |||
I am a foo-y message type, and I belong to Info Package foo | I am a foo-y message type, and I belong to Info Package foo | |||
--theboundary-- | --theboundary-- | |||
12.2.2.3. Info Package with single body part inside multipart body part | 12.2.2.3. Info Package with Single Body Part inside Multipart Body Part | |||
The body part payload associated with the Info Package can have a | The body part payload associated with the Info Package can have a | |||
Content-Disposition header field value other than "Info-Package". In | Content-Disposition header field value other than "Info-Package". In | |||
this case, the body part is put into a Multipart MIME body, with a | this case, the body part is put into a multipart MIME body, with a | |||
Content-Disposition header field that indicates which body part is | Content-Disposition header field that indicates which body part is | |||
associated with the Info Package. | associated with the Info Package. | |||
INFO sip:alice@pc33.example.com SIP/2.0 | INFO sip:alice@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | |||
To: Alice <sip:alice@example.net>;tag=1234567 | To: Alice <sip:alice@example.net>;tag=1234567 | |||
From: Bob <sip:bob@example.com>;tag=abcdefg | From: Bob <sip:bob@example.com>;tag=abcdefg | |||
Call-Id: a84b4c76e66710@pc33.example.com | Call-Id: a84b4c76e66710@pc33.example.com | |||
CSeq: 314423 INFO | CSeq: 314423 INFO | |||
Info-Package: foo | Info-Package: foo | |||
skipping to change at page 31, line 27 | skipping to change at page 30, line 45 | |||
Content-Type: application/foo-x | Content-Type: application/foo-x | |||
Content-Disposition: icon | Content-Disposition: icon | |||
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 of rogue SIP UAs | |||
from confusing another UA by purposely sending unrelated INFO | confusing another UA by purposely sending unrelated INFO requests, we | |||
requests, we expect this document's clarification of the use of INFO | expect this document's clarification of the use of INFO to improve | |||
to improve the security of the Internet. Whilst rogue UAs can still | the security of the Internet. While rogue UAs can still send | |||
send unrelated INFO requests, this mechanism provides mechanisms for | unrelated INFO requests, this mechanism enables the UAS and other | |||
which the UAS and other security devices can associate INFO requests | security devices to 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 (B2BUAs), 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 that INFO messages may require a higher level | |||
protection than the underlying SIP dialog signaling. In particular, | of protection than the underlying SIP dialog signaling. In | |||
if one does not protect the SIP signaling from eavesdropping or | particular, if one does not protect the SIP signaling from | |||
authentication and repudiation attacks, for example by using TLS | eavesdropping or authentication and repudiation attacks, for example | |||
transport, then the INFO request and its contents will be vulnerable, | by using TLS transport, then the INFO request and its contents will | |||
as well. Even with SIP/TLS, any SIP hop along the path from UAC to | be vulnerable as well. Even with SIP/TLS, any SIP hop along the path | |||
UAS can view, modify, or intercept INFO requests, as they can with | from UAC to UAS can view, modify, or intercept INFO requests, as they | |||
any SIP request. This means some applications may require end-to-end | can with any SIP request. This means some applications may require | |||
encryption of the INFO payload, beyond, for example, hop-by-hop | end-to-end encryption of the INFO payload, beyond, for example, hop- | |||
protection of the SIP signaling itself. Since the application | by-hop protection of the SIP signaling itself. Since the application | |||
dictates the level of security required, individual Info Packages | dictates the level of security required, individual Info Packages | |||
have to enumerate these requirements. In any event, the Info Package | have to enumerate these requirements. In any event, the Info Package | |||
mechanism described by this document provides the tools for such | mechanism described by this document provides the tools for such | |||
secure, end-to-end transport of application data. | secure, end-to-end transport of application data. | |||
One interesting property of Info Package use is one can reuse the | One interesting property of Info Package usage is that one can re-use | |||
same digest-challenge mechanism used for INVITE based authentication | the same digest-challenge mechanism used for INVITE-based | |||
for the INFO request. For example, one could use a quality-of- | authentication for the INFO request. For example, one could use a | |||
protection (qop) value of authentication with integrity (auth-int), | quality-of-protection (qop) value of authentication with integrity | |||
to challenge the request and its body, and prevent intermediate | (auth-int), to challenge the request and its body, and prevent | |||
devices from modifying the body. However this assumes the device | intermediate devices from modifying the body. However, this assumes | |||
which knows the credentials in order to perform the INVITE challenge | the device that knows the credentials in order to perform the INVITE | |||
is still in the path for the INFO, or that the far-end UAS knows such | challenge is still in the path for the INFO request, or that the far- | |||
credentials. | end UAS knows such credentials. | |||
14. References | 14. References | |||
14.1. Normative References | 14.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
skipping to change at page 34, line 9 | skipping to change at page 33, line 28 | |||
[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. | |||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | ||||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | ||||
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines | [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines | |||
for Application Designers", BCP 145, RFC 5405, | for Application Designers", BCP 145, RFC 5405, | |||
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., McGlashan, S., Lee, A., Auburn, R., Carter, | Porter, B., Oshry, M., Rehor, K., Auburn, R., Bodell, M., | |||
J., Rehor, K., Oshry, M., Bodell, M., Burke, D., Baggia, | Carter, J., Burke, D., Baggia, P., Candell, E., Burnett, | |||
P., Candell, E., and D. Burnett, "Voice Extensible Markup | D., McGlashan, S., and A. Lee, "Voice Extensible Markup | |||
Language (VoiceXML) 2.1", World Wide Web Consortium | Language (VoiceXML) 2.1", World Wide Web Consortium | |||
Recommendation REC-voicexml21-20070619, June 2007, | Recommendation REC-voicexml21-20070619, June 2007, | |||
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>. | <http://www.w3.org/TR/2007/REC-voicexml21-20070619>. | |||
[I-D.ietf-speechsc-mrcpv2] | [SPEECHSC-MRCPv2] | |||
Burnett, D. and S. Shanmugham, "Media Resource Control | Burnett, D. and S. Shanmugham, "Media Resource Control | |||
Protocol Version 2 (MRCPv2)", | Protocol Version 2 (MRCPv2)", Work in Progress, | |||
draft-ietf-speechsc-mrcpv2-21 (work in progress), | November 2010. | |||
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. Acknowledgements | Appendix A. Acknowledgements | |||
The work on this document was influenced by the "INFO Considered | The work on this document was influenced by "The Session Initiation | |||
Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and | Protocol (SIP) INFO Considered Harmful" (26 December 2002) written by | |||
by the "Packaging and Negotiation of INFO Methods for the Session | Jonathan Rosenberg, and by "Packaging and Negotiation of INFO Methods | |||
Initiation Protocol" draft (15 January 2003) written by Dean Willis. | for the Session Initiation Protocol" (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, Jonathan | |||
Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard | Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, | |||
Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael | Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul | |||
Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, | Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, | |||
Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore | Robert Sparks, Roland Jesske, Roni Even, Salvatore Loreto, Sam | |||
Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve | Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit | |||
Langstaff, Sumit Garg and Xavier Marjoum. | Garg, and Xavier Marjoum. | |||
John Elwell and Francois Audet helped with QSIG references. In | John Elwell and Francois Audet helped with QSIG references. In | |||
addition, Francois Audet provided text for the revised abstract. | addition, Francois Audet provided text for the revised abstract. | |||
Keith Drage provided comments and helped immensely with Figure 1. | Keith Drage provided comments and helped immensely with Table 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 working group last call | |||
to prepare this document for publication. | process, in order 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 B. Change Log | ||||
[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 | ||||
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 | ||||
o Further changes based on WGLC comments | ||||
o Editorial changes | ||||
o IANA registry procedures clarified | ||||
Changes from draft-ietf-sipcore-info-events-04 | ||||
o Further changes based on WGLC comments | ||||
o OPTIONS processing removed | ||||
o Clarification of Recv-Info header field in INFO 469 response added | ||||
o IANA registry procedures clarified | ||||
Changes from draft-ietf-sipcore-info-events-03 | ||||
o Further changes based on WGLC comments | ||||
o New section 3.2.3 added | ||||
Changes from draft-ietf-sipcore-info-events-02 | ||||
o Further changes based on WGLC comments | ||||
o alignment with "specification" and "definition" terminology | ||||
o Location switch of sections 3 and 4 | ||||
o Corrections in header table | ||||
o IANA Info Package registration input changed | ||||
o Clarification regarding which SIP messages can contain the Recv- | ||||
Info header field | ||||
o Recv-Info 'nil' value removed | ||||
o Rules on usage of Recv-Info header clarified | ||||
o Recv-Info fallback rules added | ||||
o Additional examples added | ||||
Changes from draft-ietf-sipcore-info-events-01 | ||||
o Further changes based on WGLC comments | ||||
o Appending A moved into the main part of the document | ||||
o Section name changed from "Modifications to SIP Change Process" to | ||||
"Security Considerations" | ||||
o "Syntax" section moved further up in the document | ||||
o Clarification on usage of Info Package related message body parts, | ||||
and the usage of the Content-Disposition header field with those | ||||
body parts | ||||
o Removed REFER and NOTIFY from the INFO Headers table | ||||
o Clarified usage of the Recv-Info header field in the REGISTER and | ||||
OPTIONS requests | ||||
o Major re-write of the Introduction section | ||||
o Text about legacy INFO and subscription-based events moved from | ||||
the Introduction to the main part of the document | ||||
o Wording about receiving Info-Packages has been replaced with | ||||
wording about receiving INFO requests for Info-Packages | ||||
o The text about the usage of message body, and body parts, | ||||
associated with Info Packages, has been clarified | ||||
Changes from draft-ietf-sip-info-events-04 | ||||
o Major re-write of the document, due to problems to implement WGLC | ||||
comments into the existing text structure | ||||
o Wording alignment | ||||
o Clarification or roles | ||||
Changes from draft-ietf-sip-info-events-03 | ||||
o Clarified Abstract language | ||||
o All SIP dialogs are now referred to as sessions | ||||
o Clarified the image example in the Introduction | ||||
o Clarified the relationship (none) between SIP Event Packages and | ||||
SIP Info Packages | ||||
o Really, really clarified the protocol is NOT a negotiation but an | ||||
advertisement | ||||
o Split Section 3 into UAS and UAC behavior | ||||
o Moved the example in section 3 into its own sub-section, and used | ||||
full SIP header fields | ||||
o Clarified forking behavior | ||||
o Clarified language around when to send a body | ||||
o Added 469 error response, instead of reusing 489 | ||||
o Clarified overlapping INFO method handling | ||||
o Fixed table 1 to follow 3261, not 2543 | ||||
o Added REFER to the INFO Headers table | ||||
o Replaced token-nodot with token for Info-Package header field | ||||
values | ||||
o Clarified end-to-end security considerations | ||||
o Info Package parameters are semi-colon delimited, not dot | ||||
delimited | ||||
Changes from -02 | ||||
o Applicability statement explicitly says we're backwards compatible | ||||
o Explicitly state we work like UPDATE (both early and confirmed | ||||
dialogs) | ||||
o Agreed text for IANA Considerations package registry | ||||
Changes from -01 | ||||
o One and only one Info Package per INFO | ||||
o Removed Send-Info header field, greatly simplifying negotiation | ||||
o Multiple body part identification through Content-Disposition: | ||||
Info-Package | ||||
o Note that forking INVITEs may result in multiple INFOs coming back | ||||
to INVITE originator | ||||
o Describe how a UAS can enforce strict adherence to this document | ||||
o Remove CANCEL INFO faux pas | ||||
o Better explained overlapping INFO issues and resolutions | ||||
o Token names are now really case sensitive | ||||
o Moved Info Package Considerations to an Appendix | ||||
o Introduced stronger, yet more open, IANA registration process | ||||
o Took a few more paragraphs from INFO Litmus to cover all bases. | ||||
o Added RFC 5168 to legacy usages | ||||
Changes from -00 | ||||
o Corrected ABNF. | ||||
o Enabled sending of legacy INFO messages. Receiving legacy INFO | ||||
messages was already here. | ||||
o Negotiation is not Offer/Answer, it is Offer/Offer. | ||||
o Created the explicit "nil" Info Package to indicate no info | ||||
package. | ||||
o Fixed CANCEL impacting future transactions. | ||||
o Added Registrar behavior. | ||||
o Added OPTIONS processing. | ||||
o Clarified overlapping INFO method processing. | ||||
o Described multiple INFO bodies in a single INFO method. | ||||
o Took out Info-Package as a header field for responses to the INFO | ||||
method. | ||||
o Expanded on risks of using INFO and filled-in more on the | ||||
alternatives | ||||
o Moved definitions of INFO into the body of the text and cleaned up | ||||
IANA Considerations section | ||||
o Added legacy usages descriptions | ||||
Authors' Addresses | Authors' Addresses | |||
Christer Holmberg | Christer Holmberg | |||
Ericsson | Ericsson | |||
Hirsalantie 11 | Hirsalantie 11 | |||
Jorvas, 02420 | Jorvas, 02420 | |||
Finland | Finland | |||
Phone: | EMail: christer.holmberg@ericsson.com | |||
Fax: | ||||
Email: christer.holmberg@ericsson.com | ||||
URI: | ||||
Eric W. Burger | Eric W. Burger | |||
NeuStar, Inc. | Georgetown University | |||
46000 Center Oak Plaza | ||||
Sterling, VA 20166-6579 | ||||
USA | ||||
Email: eburger@standardstrack.com | EMail: eburger@standardstrack.com | |||
URI: http://www.standardstrack.com | URI: http://www.standardstrack.com | |||
Hadriel Kaplan | Hadriel Kaplan | |||
Acme Packet | Acme Packet | |||
71 Third Ave. | 100 Crosby Drive | |||
Burlington, MA 01803 | Bedford, MA 01730 | |||
USA | USA | |||
Phone: | EMail: hkaplan@acmepacket.com | |||
Fax: | ||||
Email: hkaplan@acmepacket.com | ||||
URI: | ||||
End of changes. 186 change blocks. | ||||
690 lines changed or deleted | 574 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |