draft-ietf-sipcore-info-events-02.txt | draft-ietf-sipcore-info-events-03.txt | |||
---|---|---|---|---|
SIPCORE E. Burger | SIPCORE E. Burger | |||
Internet-Draft NeuStar, Inc. | Internet-Draft NeuStar, Inc. | |||
Obsoletes: RFC 2976 H. Kaplan | Obsoletes: RFC 2976 H. Kaplan | |||
(if approved) Acme Packet | (if approved) Acme Packet | |||
Expires: April 26, 2010 C. Holmberg | Expires: June 5, 2010 C. Holmberg | |||
Ericsson | Ericsson | |||
October 23, 2009 | December 2, 2009 | |||
Session Initiation Protocol (SIP) INFO Method and Package Framework | Session Initiation Protocol (SIP) INFO Method and Package Framework | |||
draft-ietf-sipcore-info-events-02 | draft-ietf-sipcore-info-events-03 | |||
Abstract | ||||
This document defines a new method, INFO, for the Session Initiation | ||||
Protocol (SIP) [RFC3261], and an Info Package mechanism. The | ||||
document obsoletes [RFC2976]. For backward compatibility the | ||||
document also specifies a "legacy" mode of usage of the INFO method | ||||
that is compatible with the usage previously defined in [RFC2976], | ||||
referred to as "legacy INFO Usage" in this document. | ||||
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]. | ||||
The terminology in this document conforms to the Internet Security | ||||
Glossary [RFC4949]. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
skipping to change at page 1, line 35 | skipping to change at page 2, line 6 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on April 26, 2010. | This Internet-Draft will expire on June 5, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
This document defines a new method, INFO, for the Session Initiation | described in the BSD License. | |||
Protocol (SIP) [RFC3261], and an Info Package mechanism. The | ||||
document obsoletes [RFC2976]. For backward compatibility the | ||||
document also specifies a "legacy" mode of usage of the INFO method | ||||
that is compatible with the usage previously defined in [RFC2976], | ||||
referred to as "legacy INFO Usage" in this document. | ||||
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]. | ||||
The terminology in this document conforms to the Internet Security | ||||
Glossary [RFC4949]. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Info Package Support . . . . . . . . . . . . . . . . . . . . . 6 | 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 6 | 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.3. Package Versioning . . . . . . . . . . . . . . . . . . . 7 | 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 | |||
3.4. REGISTER Processing . . . . . . . . . . . . . . . . . . . 7 | 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 | |||
3.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 8 | 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 | |||
4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 | |||
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 | |||
4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 8 | 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 | |||
4.3. INFO Request Message Body . . . . . . . . . . . . . . . . 9 | 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.4. INFO Response . . . . . . . . . . . . . . . . . . . . . . 10 | 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.5. INFO Response Message Body . . . . . . . . . . . . . . . 11 | 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 | |||
4.6. Order of Delivery . . . . . . . . . . . . . . . . . . . . 11 | 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11 | 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 | |||
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 | |||
6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13 | 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 | |||
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 | |||
6.2. Info-Package header field . . . . . . . . . . . . . . . . 13 | 4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12 | |||
6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14 | 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 | |||
7. Info Package Considerations . . . . . . . . . . . . . . . . . 14 | 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 | |||
7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14 | 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
7.3. Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 14 | 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 | |||
7.4. INFO Request Rate and Volume . . . . . . . . . . . . . . 14 | 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 | |||
7.5. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15 | 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 | |||
7.5.1. Alternative SIP signaling plane mechanisms . . . . . . 15 | 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.5.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16 | 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 | |||
7.5.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 | 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 | |||
7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 | ||||
7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 | ||||
7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 | ||||
7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 | ||||
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.3. Co-existence with Info Package based INFO usage . . . . . 18 | 9.3. Co-existence with Info Package based INFO usage . . . . . 19 | |||
10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 | 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 | |||
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
10.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 | 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 | |||
10.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 19 | 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10.4. Info Package Parameters . . . . . . . . . . . . . . . . . 20 | 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 | |||
10.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 20 | 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 | |||
10.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 20 | 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 | |||
10.7. Info Package Usage Restrictions . . . . . . . . . . . . . 20 | 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 | |||
10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 21 | 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 | |||
10.9. IANA Registrations . . . . . . . . . . . . . . . . . . . 21 | 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 | |||
10.10. Info Package Security Considerations . . . . . . . . . . 21 | 10.10. Info Package Security Considerations . . . . . . . . . . 22 | |||
10.11. Application Procedures . . . . . . . . . . . . . . . . . 22 | 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 | |||
10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 22 | 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
11.1. Update to Registration of SIP INFO Method . . . . . . . . 22 | 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 | |||
11.2. Registration of the Info-Package Header Field . . . . . . 22 | 11.2. Registration of the Info-Package Header Field . . . . . . 24 | |||
11.3. Registration of the Recv-Info Header Field . . . . . . . 23 | 11.3. Registration of the Recv-Info Header Field . . . . . . . 24 | |||
11.4. Creation of the Info Packages Registry . . . . . . . . . 23 | 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 | |||
11.5. Registration of the Info-Package Content-Disposition . . 24 | 11.5. Registration of the Info-Package Content-Disposition . . 25 | |||
11.6. SIP Response Code 469 Registration . . . . . . . . . . . 24 | 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 | |||
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
12.1. Indication of which Info Packages UAs are willing to | 12.1. Indication for which Info Packages UAs are willing to | |||
receive INFO requests within an invite dialog usage . . . 24 | receive INFO requests . . . . . . . . . . . . . . . . . . 25 | |||
12.2. INFO request with information associated with a | 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 | |||
simple Info Package . . . . . . . . . . . . . . . . . . . 25 | 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 | |||
12.3. Multipart INFO Example . . . . . . . . . . . . . . . . . 25 | 12.2. INFO request associated with Info Package . . . . . . . . 27 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 | 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 28 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
Appendix A. Legacy INFO Usages . . . . . . . . . . . . . . . . . 30 | 14.1. Normative References . . . . . . . . . . . . . . . . . . 31 | |||
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30 | 14.2. Informative References . . . . . . . . . . . . . . . . . 31 | |||
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34 | |||
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30 | A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 31 | A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31 | A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31 | A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 | Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 | |||
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||
1. Introduction | 1. Introduction | |||
This document defines a new method, INFO, for the Session Initiation | This document defines a new method, INFO, for the Session Initiation | |||
Protocol (SIP) [RFC3261]. | Protocol (SIP) [RFC3261]. | |||
The purpose of the INFO message is to carry application level | The purpose of the INFO message is to carry application level | |||
information between endpoints, using the SIP dialog signaling path. | information between endpoints, using the SIP dialog signaling path. | |||
Note that the INFO method is not used to update characteristics of a | Note that the INFO method is not used to update characteristics of a | |||
SIP dialog or session, but to allow the applications which use the | SIP dialog or session, but to allow the applications which use the | |||
SIP session to exchange information (which may update the state of | SIP 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. | ||||
INFO messages are always part of, and share the fate of, an invite | ||||
dialog usage [RFC5057]. INFO messages cannot be sent as part of | ||||
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 UAs to | |||
for which Info Packages they are willing to receive INFO requests. | indicate for which Info Packages they are willing to receive INFO | |||
The document defines how the INFO method is used, new SIP header | requests, and which Info Package a specific INFO request is | |||
fields for the INFO method, and how to transport payload information | associated with. | |||
associated with an Info Package using INFO requests. | ||||
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 | ||||
dialog usage [RFC5057]. INFO messages cannot be sent as part of | ||||
other dialog usages. | ||||
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 the Recv-Info header field with a 'nil' value to | NOTE: A UA can use an empty Recv-Info header field (a header field | |||
indicate that it is not willing to receive INFO requests for any | without a value) to indicate that it is not willing to receive INFO | |||
Info-Package, but to inform other UAs that it still supports the Info | requests for any Info-Package, but to inform other UAs that it still | |||
Package mechanism. | supports the Info Package mechanism. | |||
When a UA sends an INFO request, it uses the Info-Package header | When a UA sends an INFO request, it uses the Info-Package header | |||
field to indicate which Info Package is associated with the request. | field to indicate which Info Package is associated with the request. | |||
One particular INFO request can only be associated with a single Info | One particular INFO request can only be associated with a single Info | |||
Package. | Package. | |||
This document obsoletes [RFC2976]. However, for backward | This document obsoletes [RFC2976]. However, for backward | |||
compatibility it specifies a "legacy" mode of usage of the INFO | compatibility it specifies a "legacy" mode of usage of the INFO | |||
method that is compatible with the usage previously defined in | method that is compatible with the usage previously defined in | |||
[RFC2976], referred to as "legacy INFO Usage" in this document. | [RFC2976], referred to as "legacy INFO Usage" in this document. | |||
2. Applicability | 2. Applicability | |||
This document defines a new method, INFO, for the Session Initiation | This document defines a new method, INFO, for the Session Initiation | |||
Protocol (SIP) [RFC3261], and an Info Package mechanism. The | Protocol (SIP) [RFC3261], and an Info Package mechanism. The | |||
document obsoletes [RFC2976]. For backward compatibility the | document obsoletes [RFC2976]. For backward compatibility the | |||
document also specifies a "legacy" mode of usage of the INFO method | document also specifies a "legacy" mode of usage of the INFO method | |||
that is compatible with the usage previously defined in [RFC2976], | that is compatible with the usage previously defined in [RFC2976], | |||
referred to as "legacy INFO Usage" in this document. | referred to as "legacy INFO Usage" in this document. | |||
3. Info Package Support | 3. The INFO Method | |||
3.1. General | 3.1. General | |||
This section describes how SIP UAs indicate for which Info Packages | The INFO method provides a mechanism for transporting application | |||
they are willing to receive INFO requests. | level information that can further enhance a SIP application. Annex | |||
A gives more details on the types of applications for which the use | ||||
of INFO is appropriate. | ||||
3.2. User Agent Behavior | This section describes how a UA handles INFO requests and responses, | |||
as well as the message bodies included in INFO messages. | ||||
A UA which supports the Info Package mechanism MUST indicate, using | 3.2. INFO Request | |||
the Revc-Info header field, the set of Info Packages for which it is | ||||
willing to receive INFO request. A UA can list multiple Info | ||||
Packages in a single Recv-Info header field, and the UA can use | ||||
multiple Recv-Info header fields. | ||||
The indication of Info Packages can take place during the dialog | 3.2.1. INFO Request Sender | |||
establishment, and during a target refresh. This includes INVITE, | ||||
UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx | ||||
only). Note that the UAC is not required to indicate its set of Info | ||||
Packages in the initial INVITE request. | ||||
If a UA is not willing to INFO requests for any Info Packages, during | An INFO request can be associated with an Info Package (see X), or | |||
dialog establishment or later during the invite dialog usage, the UA | associated with a legacy INFO usage (see Y). | |||
MUST indicate this by including a Recv-Info header field with a 'nil' | ||||
value. This informs other UAs that the UA still supports the Info | ||||
Package mechanism. | ||||
Example: If a UA has previously indicated Info Packages 'foo' and | The construction of the INFO request is the same as any other request | |||
'bar', and the UA during the lifetime of the invite dialog usage | within an existing invite dialog usage. A UA can send INFO requests | |||
wants to indicate that it does not want to receive INFO requests for | both within early and confirmed dialogs. | |||
any Info Packages anymore, the UA sends a target refresh request with | ||||
a Recv-Info header field with a header value of 'nil'. | ||||
Once a UA has indicated that it is willing to receive INFO requests | When a UA sends an INFO request associated with an Info Package, it | |||
for a specific Info Package, and a dialog has been established, the | MUST include an Info-Package header field that indicates which Info | |||
UA MUST be prepared to receive INFO request associated with that Info | Package is associated with the request. A specific INFO request can | |||
Package. | be used only for a single Info Package. | |||
A UA MUST NOT send an INFO request associated with an Info Package | When a UA sends an INFO request associated with an legacy INFO usage | |||
until it has received an indication that the remote UA is willing to | there is no Info Package associated with the request, and the UA MUST | |||
receive INFO requests for that Info Package, and a dialog has been | NOT include an Info-Package header field in the request. | |||
established with the remote UA. | ||||
If a UA indicates multiple Info Packages, which provide similar | The INFO request MUST NOT contain a Recv-Info header field. A UA can | |||
functionality, it is not possible to indicate a priority order of the | only indicate a set of Info Packages for which it is willing to | |||
Info Packages, or that that the UA wishes to only receive INFO | receive INFO requests by using the SIP methods (and their responses) | |||
request for one of the Info Packages. It is up to the application | listed in Section 4. | |||
logic associated with the Info Packages, and specific Info Package | ||||
descriptions to describe application behavior in such cases. | ||||
For backward compatibility purpose, even if a UA indicates support of | A UA MUST NOT use the INFO method outside an invite dialog usage. | |||
the Info Package mechanism, it is still allowed to enable legacy INFO | ||||
usages Section 9. | ||||
This document does not define a SIP option tag [RFC3261] for the Info | UAs indicate, per-dialog basis, for which Info Packages they are | |||
Package mechanism. However, an Info Package specification can define | willing to receive INFO requests. The set of Info Packages cannot | |||
an option-tag associated with the specific Info Package, as described | automatically be used within other dialogs. | |||
in Section 10.5. | ||||
For backward compatibility, if a UA indicates support of the INFO | If a UA receives a 469 (Bad INFO Package) response to an INFO | |||
method using the Allow header field [RFC3261], it does not implicitly | request, based on [RFC5057] the response represents a Transaction | |||
indicate support of the Info Package mechanism. A UA MUST use the | Only failure, and the UA MUST NOT terminate the invite dialog usage. | |||
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 | ||||
field to indicate that it supports the Info Package mechanism, in | ||||
addition the UA MUST still also explicitly indicate support of the | ||||
INFO method using the Allow header field. | ||||
3.3. Package Versioning | Due to the possibility of forking, the UA whichs sends the initial | |||
INVITE reqest MUST be prepared to receive INFO requests from multiple | ||||
remote UAs during the early dialog phase. In addition, the UA MUST | ||||
be prepared to receive different Recv-Info header field values from | ||||
different remote UAs. | ||||
The Info Package mechanism does not support package versioning. | NOTE: If the UAS (receiver of the initial INVITE request) sends an | |||
Specific Info Package payloads MAY contain version information, which | INFO request just after it has sent the response which creates the | |||
is handled by the applications associated with the Info Package, but | dialog, the UAS needs to be prepared that the INFO request can reach | |||
that is outside the scope of the Info Package mechanism. | the UAC before the dialog creating response, and might therefore be | |||
rejected by the UAC. In addition, an INFO request might be rejected | ||||
due to a race condition, if a UA sends the INFO request at the same | ||||
time as the remote UA sends a new set of Info Packages for which it | ||||
is willing to receive INFO requests. | ||||
NOTE: Even if an Info Package name contains version numbering (e.g. | 3.2.2. INFO Request Receiver | |||
foo_v2), the Info Package mechanism does not distinguish a version | ||||
number from the rest of the Info Package name. | ||||
3.4. REGISTER Processing | 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 | ||||
469 (Bad INFO Package) response (see Section 11.6). In the | ||||
terminology of Multiple Dialog Usages [RFC5057], this represents a | ||||
Transaction Only failure, and does not terminate the invite dialog | ||||
usage. | ||||
This document allows a UA to insert a Recv-Info header field in a | If a UA receives an INFO request associated with an Info Package, and | |||
REGISTER request. However, a UA SHALL NOT include a header value for | the message body part associated with the Info Package contains a | |||
a specific Info Package unless the specific Info Package | message body MIME type that the UA support, but which usage is not | |||
specification describes how the header field value shall be | defined for the specific Info Package, it is RECOMMENDED that the UA | |||
interpreted and used by the registrar, e.g. in order to determine | sends a 415 (Unsupported Media Type) response. | |||
request targets. | ||||
NOTE: Rather than using the Recv-Info header field in order to | The UA MAY send other error responses, such as Request Failure (4xx), | |||
determine request targets, it is recommended to use more appropriate | Server Failure (5xx) and Global Failure (6xx), in accordance with the | |||
mechanisms, e.g. based on [RFC3840]. | error handling procedures in [RFC3261]. | |||
3.5. OPTIONS Processing | Otherwise, if the INFO request is syntactically correct and well | |||
structured, the UA MUST send a 200 (OK) response. | ||||
If a UA sends an OPTIONS request, or a response, the UA SHALL include | NOTE: If the application needs to reject the information which it | |||
Recv-Info header field in the message, and list the Info Packages | received in an INFO request, that needs to be done on the application | |||
that it supports to receive. | level. Ie the application needs to trigger a new INFO request, which | |||
contains information that the previously received application data | ||||
was not accepted. Individual Info Package specifications need to | ||||
describe the details for such procedures. | ||||
NOTE: As for any other capability and extension, for a specific | 3.3. INFO Message Body | |||
dialog UAs need to indicate which Info Packages they are willing to | ||||
receive within that dialog. | ||||
4. The INFO Method | 3.3.1. INFO Request Message Body | |||
4.1. General | The purpose of the INFO request is to carry application level | |||
information between SIP UAs. The application information data is | ||||
carried in the payload of the message body of the INFO request. | ||||
This section describes the UA handling of INFO requests and | NOTE: An INFO request assocated with an Info Package can also include | |||
responses, and message bodies carried in INFO messages. | information associated with the Info Package using Info-Package | |||
header field parameters. | ||||
The INFO method provides additional, application level information | If an INFO request associated with an Info Package contains a message | |||
that can further enhance a SIP application. Annex A gives more | body part, the body part is identified by a Content-Disposition | |||
details on the types of application for which the usage of INFO is | header field 'Info-Package' value. The body part can contain a | |||
seen as appropriate. | single MIME type, or it can be a multipart [RFC5621] which contains | |||
other body parts associated with the Info Package. | ||||
4.2. INFO Request | UAs MUST conform to [RFC5621] to support multipart body parts. | |||
When a UA sends an INFO request associated with an Info Package, it | NOTE: Some SIP functions that are orthogonal to INFO can insert body | |||
MUST include an Info-Package header field that indicates which Info | parts unrelated to the Info Package. | |||
Package is associated with the request. A specific INFO request can | ||||
be used only for a single Info Package. For a specific dialog, a UA | ||||
MUST NOT send INFO requests associated with Info Packages that the | ||||
remote UA has not indicated that it is willing to receive. | ||||
A UA can send an INFO requests associated with a legacy INFO usage | When a UA supports a specific Info-Package, the UA also support all | |||
Section 9. In such case there is no Info Package associated with the | message body MIME types associated with that Info-Package. However, | |||
usage, and the INFO request does not contain an Info-Package header | in accordance with [RFC3261] the UA still indicates the supported | |||
field. In addition, the UA cannot use the Recv-Info header field to | MIME types using the Accept header. | |||
indicate whether it is willing to receive INFO requests associated | ||||
with that legacy INFO usage. | ||||
The INFO method MUST NOT be used outside an invite dialog usage. The | 3.3.2. INFO Response Message Body | |||
INFO method has no lifetime beyond its transaction or usage of its | ||||
own. UAs indicate, per-dialog basis, for which Info Packages they | ||||
are willing to receive INFO requests. The set of Info Packages | ||||
cannot automatically be used within other dialogs. | ||||
Due to the possibility of forking, a UAC which, during the early | A UA MUST NOT include a message body associated with an Info Package | |||
dialog phase indicates that it is willing to receive INFO requests | in an INFO response. Message bodies associated with Info Packages | |||
for one or more Info Packages MUST be prepared to receive INFO | MUST only be sent in INFO requests. | |||
requests associated with those Info Packages from multiple remote | ||||
UAs. Note that each remote UA can indicate a different set of Info | ||||
Packages for which they are willing to receive INFO request. | ||||
The construction of the INFO request is the same as any other request | A UA MAY include a message body which is not associated with an Info | |||
within an existing invite dialog usage. A UA can send INFO requests | Package in an INFO response. | |||
both within early and confirmed dialogs. | ||||
The INFO request MUST NOT contain a Recv-Info header field. The UA | 3.4. Order of Delivery | |||
can only indicate a set of Info Packages for which it is willing to | ||||
receive INFO requests by using the SIP methods (and their responses) | ||||
listed in Section 3. | ||||
4.3. INFO Request Message Body | The Info Package mechanism does not define a delivery order | |||
mechanism. Info Packages can rely on the CSeq header field to detect | ||||
if an INFO request is received out of order. | ||||
The purpose of the INFO request is to carry application level | If specific applications need additional mechanisms for order of | |||
information between SIP UAs. The application data associated with an | delivery, those mechanisms, and related procedures, are specified as | |||
Info Package is carried as payload in the message body of the INFO | part of the associated Info Package, and possible sequence numbers | |||
request, using one or more body parts. | etc must be defined as application data. | |||
Info Package specifications MUST describe the application level | 4. Info Packages | |||
information associated with the Info Package. Each body part MUST | ||||
have a MIME type value, and the syntax and content of the body part, | ||||
defined. | ||||
Each body part, when associated with an Info Package, MUST have a | 4.1. General | |||
Content-Disposition header field with an 'Info-Package' value | ||||
assigned, in order to be able distinguish body parts associated with | ||||
the Info Package from other body parts. | ||||
NOTE: Some SIP functions that are orthogonal to INFO may insert body | An Info Package specification defines the content and semantics of | |||
parts unrelated to the Info Package. | the information carried in an INFO message associated with an Info | |||
Package. The Info Package mechanism provides a way for UAs to | ||||
indicate for which Info Packages they are willing to receive INFO | ||||
requests, and which Info Package a specific INFO request is | ||||
associated with. | ||||
Body parts associated with specific MIME types may sometimes have | 4.2. User Agent Behavior | |||
specific Content-Disposition header field values defined for them. | ||||
For example, for body parts with a 'text/plain' MIME a Content- | ||||
Disposition header field with a 'render' value is often assigned. | ||||
However, when a body part in the INFO message is associated with an | ||||
Info Package, it MUST always have a Content-Disposition header field | ||||
with an 'Info-Package' value assigned. The Info Package | ||||
specification defines how applications process the body part | ||||
contents. | ||||
If a SIP message body contains multiple body parts, multipart body | 4.2.1. General | |||
parts [RFC5621] are used to separate them. If all body parts within | ||||
a multipart body part are associated with the Info Package, the | ||||
multipart body part SHALL have a Content-Disposition header field | ||||
with an 'Info-Package' value assigned to it. However, each body part | ||||
within the multipart body part MUST still have a Content-Disposition | ||||
header field with an 'Info-Package' value assigned to them, in order | ||||
to avoid that the parser assigns a default Content-Disposition header | ||||
value to the body part. | ||||
NOTE: According to [RFC5621], body parts within a multipart are not | This section describes how a UA handles Info Packages, how a UA uses | |||
implicitly assigned the Content-Disposition header field value of the | the Recv-Info header field, and how the UA acts in re-INVITE rollback | |||
multipart body part which they belong to. | situations. | |||
This document does not define Info Package specific rules on how body | 4.2.2. UA Procedures | |||
parts associated with Info Packages are to be inserted into multipart | ||||
body parts, and what type of multiparts are used. If an Info Package | ||||
requires special rules regarding the usage of multipart body parts, | ||||
the specification for that Info Package MUST specify such rules. | ||||
UAs MUST conform to [RFC5621] to support multipart body parts. | A UA which supports the Info Package mechanism MUST indicate, using | |||
the Revc-Info header field, the set of Info Packages for which it is | ||||
willing to receive INFO requests. A UA can list multiple Info | ||||
Packages in a single Recv-Info header field, and the UA can use | ||||
multiple Recv-Info header fields. A UA can an empty Recv-Info header | ||||
field, ie a header field without any header field values. | ||||
If a UA indicates that it is willing to receive a specific Info | A UA provides its set of Info Packages for which it is willing to | |||
Package, the UA naturally also supports any associated message body | receive INFO requests during the dialog establishment. A UA can | |||
part MIME type associated with the Info Package. However, in | update the set of Info Packages during the invite dialog usage. | |||
addition the UA MUST still indicate support of those MIME types in | ||||
the Accept header field, according to the procedures in [RFC3261]. | ||||
NOTE: To avoid corner cases with legacy INFO usage, the Info-Package | If a UA is not willing to receive INFO requests for any Info | |||
header field is used to indicate the Info Package name, rather than | Packages, during dialog establishment or later during the invite | |||
to use a Content-Disposition header field parameter in order to | dialog usage, the UA MUST indicate this by including an empty Recv- | |||
indicate the name. | Info header field. This informs other UAs that the UA still supports | |||
the Info Package mechanism. | ||||
4.4. INFO Response | 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 | ||||
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 | ||||
message with an empty Recv-Info header field. | ||||
If a UA receives an INFO request, associated with an Info-Package | Once a UA has sent a set of Info Packages, the set is valid until the | |||
that the UA has indicated willingness to receive, and the INFO | UA sends a new set, or an empty Recv-Info header field. | |||
request contains data associated with that Info-Package, the UA MUST | ||||
send a 200 OK response. | ||||
If a UA receives an INFO request for legacy usage, for which no Info- | Once a UA has indicated that it is willing to receive INFO requests | |||
Package is associated (the INFO request does not contain an Info- | for a specific Info Package, and a dialog has been established, the | |||
Package header field), the UA MUST send a 200 OK response. | UA MUST be prepared to receive INFO request associated with that Info | |||
Package until the UA indicates that it is no longer willing to | ||||
receive INFO requests associated with that Info Package. | ||||
The UAS MAY send other responses, such as Request Failure (4xx), | For a specific dialog usage, a UA MUST NOT send an INFO request | |||
Server Failure (5xx) and Global Failure (6xx) as appropriate for the | associated with an Info Package until it has received an indication | |||
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 | ||||
UA is no longer willing to receive INFO requests associated with that | ||||
Info Package. | ||||
NOTE: When a UA sends a message which contains a Recv-Info header | ||||
field with a new set of Info Packages for which the UA is willing to | ||||
receive INFO requests the remote UA might, before it receives the | ||||
message, send an INFO request based on the old set of Info Packages. | ||||
In this case the receiver of the INFO requests rejects, and sends a | ||||
469 (Bad INFO Package) response to, the INFO request. | ||||
If a UA indicates multiple Info Packages, which provide similar | ||||
functionality, it is not possible to indicate a priority order of the | ||||
Info Packages, or that that the UA wishes to only receive INFO | ||||
request for one of the Info Packages. It is up to the application | ||||
logic associated with the Info Packages, and specific Info Package | ||||
specifications, to describe application behavior in such cases. | ||||
For backward compatibility purpose, even if a UA indicates support of | ||||
the Info Package mechanism, it is still allowed to enable legacy INFO | ||||
usages Appendix A. In addition, if a UA indicates support of the | ||||
INFO method using the Allow header field [RFC3261], it does not | ||||
implicitly 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 Package mechanism. Likewise, even if a UA uses the Recv- | ||||
Info header field to indicate that it supports the Info Package | ||||
mechanism, in addition the UA still indicates support of the INFO | ||||
method using the Allow header. | ||||
This document does not define a SIP option tag [RFC3261] for the Info | ||||
Package mechanism. However, an Info Package specification can define | ||||
an option-tag associated with the specific Info Package, as described | ||||
in Section 10.6. | ||||
4.2.3. Recv-Info header field rules | ||||
The text below defines rules on when a UA is required to include a | ||||
Recv-Info header field in SIP messages. Section 6.1 lists the SIP | ||||
methods, for which a UA can insert a Recv-Info header field in | ||||
requests and responses. | ||||
- 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 | ||||
willing to receive INFO requests asscoiated with any Info Package. | ||||
- The receiver of a request which contains a Recv-Info header field | ||||
MUST include a Recv-Info header field in a reliable 18x/2xx response | ||||
to the request, even if the request contains an empty Recv-Info | ||||
header field, and even if the header field value of the 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 | ||||
associated request did not contain a Recv-Info header field. | ||||
NOTE: Different from the rules for generating SDP answers, the | ||||
receiver of a request which contains a set of Info Packages is not | ||||
restricted to generate its own set of Info Packages as a subset of | ||||
the Info Package set received in the Info Package header field of the | ||||
request. | request. | |||
If a UA receives an INFO request associated with an Info Package that | NOTE: Similar to SDP answers, the receiver can include the same Recv- | |||
the UA has not indicated willingness to receive, the UA MUST send a | Info header field value in multiple responses (18x/2xx) for the same | |||
469 Bad INFO Package response Section 11.6. In the terminology of | INVITE/re-INVITE transaction, but the receiver is not allowed to | |||
Multiple Dialog Usages [RFC5057], this represents a Transaction Only | include a Recv-Info header field value which is different from a | |||
failure. | value that the receiver has already included in a response for the | |||
same transaction. | ||||
If a UA receives an INFO request that does not match any existing | 4.2.4. Info Package fallback rules | |||
invite dialog usage, the UA MUST send a 481 Call Leg/Transaction Does | ||||
Not Exist response. | ||||
If a UA receives an INFO request that carries a message body that the | If the receiver of a request which contains a Recv-Info header field | |||
UA does not support, and support of the message body is required in | rejects the request, both the sender and receiver of the request MUST | |||
the Content-Disposition header field, the UA MUST send a 415 | roll back to the set of Info Packages which was used before the | |||
Unsupported Media Type response. If support of the message body is | request was sent. This also applies to the case where the receiver | |||
optional, the UA MUST send a 200 OK response even if the UA does not | of an INVITE/re-INVITE request has included a Recv-Info header field | |||
support the message body. | in a provisional response, but later rejects the request. | |||
4.5. INFO Response Message Body | NOTE: The dialog state rollback rules for Info Packages might differ | |||
from the rules for other types of dialog state information (SDP, | ||||
target, etc). | ||||
The Info Package mechanism allows a SIP stack to generate a response | 4.3. REGISTER Processing | |||
to an INFO request without application interaction. As a result, | ||||
Info Packages cannot require a message body in INFO responses, | ||||
require different response codes, or otherwise require the response | ||||
to the INFO request to contain application information. If the | ||||
application needs to send information in the other direction, it can | ||||
send a new INFO request which contains the information. | ||||
4.6. Order of Delivery | 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 | ||||
a specific Info Package unless the specific Info Package | ||||
specification describes how the header field value shall be | ||||
interpreted and used by the registrar, e.g. in order to determine | ||||
request targets. | ||||
The Info Package mechanism relies on the CSeq header field to detect | Rather than using the Recv-Info header field in order to determine | |||
if an INFO request is received out of order. | request targets, it is recommended to use more appropriate | |||
mechanisms, e.g. based on [RFC3840]. However, this document does not | ||||
define a feature tag for the Info Package mechanism, or a mechanism | ||||
to define feature tags for specific Info Packages. | ||||
If specific applications need additional mechanisms for order of | 4.4. OPTIONS Processing | |||
delivery, those mechanisms, and related procedures, must be specified | ||||
as part of the associated Info Package, and possible sequence numbers | If a UA sends an OPTIONS request, or a response, the UA SHALL include | |||
etc must be defined as application data. | Recv-Info header field in the message, and list the Info Packages | |||
that it supports to receive. | ||||
NOTE: As for any other capability and extension, for a specific | ||||
dialog UAs need to indicate which Info Packages they are willing to | ||||
receive within that dialog. | ||||
5. Formal INFO Method Definition | 5. Formal INFO Method Definition | |||
5.1. INFO Method | 5.1. INFO Method | |||
This document describes one new SIP method: INFO. This document | This document describes one new SIP method: INFO. This document | |||
replaces the definition and registrations found in [RFC2976]. | replaces the definition and registrations found in [RFC2976]. | |||
This table expands on Tables 2 and 3 in [RFC3261]. | This table expands on Tables 2 and 3 in [RFC3261]. | |||
Header Where INFO | Header Where INFO | |||
------ ----- ---- | ------ ----- ---- | |||
Accept R o | Accept R 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 c | Accept-Language 415 o | |||
Accept-Resource-Priority 2xx,417 o | ||||
Alert-Info - | Alert-Info - | |||
Allow R o | Allow R o | |||
Allow 200 - | Allow 405 m | |||
Allow 405 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 | ||||
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 o | Organization - | |||
Priority R - | Priority R - | |||
Privacy R o | Privacy o | |||
Proxy-Authenticate 401 m | ||||
Proxy-Authenticate 407 o | Proxy-Authenticate 407 o | |||
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 | ||||
Request-Disposition R o | ||||
Require o | Require o | |||
Resource-Priority o | ||||
Retry-After R - | Retry-After R - | |||
Retry-After 404,480,486 o | Retry-After 404,413,480,486 o | |||
Retry-After 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 | |||
skipping to change at page 13, line 30 | skipping to change at page 14, line 25 | |||
6. INFO Header Fields | 6. INFO Header Fields | |||
6.1. General | 6.1. General | |||
This table expands on tables 2 and 3 in [RFC3261]. | This table expands on tables 2 and 3 in [RFC3261]. | |||
Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR | Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR | |||
------------------------------------------------------------------------ | ------------------------------------------------------------------------ | |||
Info-Package R - - - - - - - m* - - - - - | Info-Package R - - - - - - - m* - - - - - | |||
Recv-Info R o - - o o o o - - o - - - | Info-Package 469 - - - - - - - m* - - - - - | |||
Recv-Info 2xx o - - o o - o - - o - - - | Recv-Info R - - - m m o o - - o - - - | |||
Recv-Info 1xx o - - o o - o - - o - - - | Recv-Info 2xx - - - o** m - o***- - o***- - - | |||
Recv-Info r o - - - o - o - - o - - - | Recv-Info 1xx - - - o** - - - - - - - - - | |||
Recv-Info r - - - o o - o - - o - - - | ||||
* The Info-Package header field is MANDATORY for INFO requests | The support and usage of the Info-Package and Recv-Info header fields | |||
associated with Info Packages. The Info-Package header field is not | is not applicalbe to UAs that only support legacy INFO usages. * Not | |||
applicable for legacy usage INFO requests [RFC2976]. | applicalbe to INFO requests and responses associated with legacy INFO | |||
usages. ** Mandatory in at least one reliable 18x/2xx response, if | ||||
sent, to the INVITE request, if the associated INVITE request | ||||
contained a Recv-Info header field. *** Mandatory if the associated | ||||
request contained a Recv-Info header field. | ||||
Table 2: INFO-related Header Fields | Table 2: INFO-related Header Fields | |||
6.2. Info-Package header field | 6.2. Info-Package header field | |||
This document adds Info-Package to the definition of the element | This document adds Info-Package to the definition of the element | |||
"message-header" in the SIP message grammar [RFC3261]. Section 4 | "message-header" in the SIP message grammar [RFC3261]. Section 3 | |||
describes the Info-Package header field usage. | describes the Info-Package header field usage. | |||
For the purposes of matching Info Package types indicated in Recv- | For the purposes of matching Info Package types indicated in Recv- | |||
Info with those in the Info-Package header field value, one compares | Info with those in the Info-Package header field value, one compares | |||
the Info-package-name portion of the Info-package-type portion of the | the Info-package-name portion of the Info-package-type portion of the | |||
Info-Package header field octet-by-octet with that of the Recv-Info | Info-Package header field octet-by-octet with that of the Recv-Info | |||
header field value. That is, the Info Package name is case | header field value. That is, the Info Package name is case | |||
sensitive. Info-package-param is not part of the comparison-checking | sensitive. Info-package-param is not part of the comparison-checking | |||
algorithm. | algorithm. | |||
This document does not define values for Info-Package types. | This document does not define values for Info-Package types. | |||
Individual Info Package specifications define these values. Such | Individual Info Package specifications define these values. | |||
specifications MUST register the values with IANA. These values are | ||||
Specification Required [RFC5226]. | ||||
6.3. Recv-Info header field | 6.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 3 | "message-header" in the SIP message grammar [RFC3261]. Section 4 | |||
describes the Recv-Info header field usage. | describes the Recv-Info header field usage. | |||
7. Info Package Considerations | 7. Info Package Considerations | |||
7.1. General | 7.1. General | |||
This section covers considerations to take into account when deciding | This section covers considerations to take into account when deciding | |||
whether the usage of an Info Package is appropriate for transporting | whether the usage of an Info Package is appropriate for transporting | |||
of application information for a specific use-case. | of application information for a specific use-case. | |||
7.2. Appropriateness of Info Package Usage | 7.2. Appropriateness of Info Package Usage | |||
When designing an Info Package, for application level information | When designing an Info Package, for application level information | |||
exchange, it is important to consider: is signaling, using INFO | exchange, it is important to consider: is signaling, using INFO | |||
requests, within a SIP dialog, an appropriate mechanism for the use- | requests, within a SIP dialog, an appropriate mechanism for the use- | |||
case? Is it because it is the most reasonable and appropriate | case? Is it because it is the most reasonable and appropriate | |||
choice, or merely because "it's easy"? Choosing an inappropriate | choice, or merely because "it's easy"? Choosing an inappropriate | |||
mechanism for a specific use-case can cause negative effects in SIP | mechanism for a specific use-case can cause negative effects in SIP | |||
networks where the mechanism is used. | networks where the mechanism is used. | |||
7.3. Dialog Fate Sharing | 7.3. INFO Request Rate and Volume | |||
As described in [RFC5057], an INFO request is always part of an | ||||
INVITE dialog usage. | ||||
One needs to consider the fate of the dialog usage of an INFO request | ||||
is rejected. In some cases it may be acceptable that the whole | ||||
dialog usage is terminated, while in other cases is is desirable to | ||||
maintain the dialog usage. | ||||
7.4. INFO Request Rate and Volume | ||||
There is no default throttling mechanism for INFO requests. Apart | There is no default throttling mechanism for INFO requests. Apart | |||
from the SIP session establishment, the number of SIP messages | from the SIP session establishment, the number of SIP messages | |||
exchanged during the lifetime a normal SIP session is rather small. | exchanged during the lifetime a normal SIP session is rather small. | |||
Some applications, like sending of DTMF tones, can generate a burst | Some applications, like sending of DTMF tones, can generate a burst | |||
of up to 20 messages per second. Other applications, like constant | of up to 20 messages per second. Other applications, like constant | |||
GPS location updates, could generate a high rate of INFO requests | GPS location updates, could generate a high rate of INFO requests | |||
during the lifetime of the invite dialog usage. | during the lifetime of the invite dialog usage. | |||
Furthermore, SIP messages tend to be relatively small, on the order | Furthermore, SIP messages tend to be relatively small, on the order | |||
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct | of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct | |||
exchange of bulk data beyond these limits, especially if the headers | exchange of bulk data beyond these limits, especially if the headers | |||
plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for | plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for | |||
such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user | such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user | |||
plane data transport mechanisms. | plane data transport mechanisms. | |||
7.5. Alternative Mechanisms | 7.4. Alternative Mechanisms | |||
7.5.1. Alternative SIP signaling plane mechanisms | 7.4.1. Alternative SIP signaling plane mechanisms | |||
7.5.1.1. General | 7.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. | |||
7.5.1.2. SUBSCRIBE/NOTIFY | 7.4.1.2. SUBSCRIBE/NOTIFY | |||
An alternative for application level interaction is to use | An alternative for application level interaction is to use | |||
subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and | subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and | |||
NOTIFY methods. Using that mechanism, a user agent requests state | NOTIFY methods. Using that mechanism, a UA requests state | |||
information, such as key pad presses from a device to an application | information, such as key pad presses from a device to an application | |||
server or key map images from an application server to a device. | server or key map images from an application server to a device. | |||
Event Packages [RFC3265] perform the role of disambiguating the | Event Packages [RFC3265] perform the role of disambiguating the | |||
context of a message for subscription-based events. The Info Package | context of a message for subscription-based events. The Info Package | |||
mechanism provides similar functionality for application information | mechanism provides similar functionality for application information | |||
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 new | existing invite dialog usage, a SUBSCRIBE request creates a separate | |||
session and a subscription dialog usage [RFC5057] which is separate, | dialog usage [RFC5057], and is normally sent outside an existing | |||
and does not share the fate any other sessions. | 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 sessions | and B2BUAs, the resource impact caused by the subscription dialogs | |||
needs to be considered. The number of subscription sessions per user | needs to be considered. The number of subscription dialogs per user | |||
also needs to be considered. | also needs to be considered. | |||
As for any other SIP signaling plane based mechanism for transporting | As for any other SIP signaling plane based mechanism for transporting | |||
application information, the SUBSCRIBE/NOTIFY messages can put a | application information, the SUBSCRIBE/NOTIFY messages can put a | |||
significant burden on intermediate SIP entities which are part of the | significant burden on intermediate SIP entities which are part of the | |||
dialog route set, but do not have any interest in the application | dialog route set, but do not have any interest in the application | |||
information transported between the end users. | information transported between the end users. | |||
7.5.1.3. MESSAGE | 7.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 | |||
ser. | ser. | |||
7.5.2. Media Plane Mechanisms | 7.4.2. Media Plane Mechanisms | |||
7.5.2.1. General | 7.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 intermediates routing to examine the | for the SIP signaling intermediates routing to examine the | |||
information, it is recommended to use a media plane mechanism, rather | information, it is recommended to use a media plane mechanism, rather | |||
than a SIP signaling based. | than a SIP signaling based. | |||
A low latency requirement for the exchange of information is one | A low latency requirement for the exchange of information is one | |||
strong indicator for using a media channel. Exchanging information | strong indicator for using a media channel. Exchanging information | |||
through the SIP routing network can introduce hundreds of | through the SIP routing network can introduce hundreds of | |||
milliseconds of latency. | milliseconds of latency. | |||
7.5.2.2. MRCPv2 | 7.4.2.2. MRCPv2 | |||
One mechanism for media plane exchange of application data is MRCPv2 | One mechanism for media plane exchange of application data is MRCPv2 | |||
[I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented | [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented | |||
channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is | channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is | |||
established. | established. | |||
7.5.2.3. MRSP | 7.4.2.3. MRSP | |||
MSRP [RFC4975] defines session-based instant messaging as well as | MSRP [RFC4975] defines session-based instant messaging as well as | |||
bulk file transfer and other such large-volume uses. | bulk file transfer and other such large-volume uses. | |||
7.5.3. Non-SIP related mechanisms | 7.4.3. Non-SIP related mechanisms | |||
Another alternative is to use a totally externally signaled channel, | Another alternative is to use a totally externally signaled channel, | |||
such as HTTP [RFC2616]. In this model, the user agent knows about a | such as HTTP [RFC2616]. In this model, the UA knows about a | |||
rendezvous point to direct HTTP requests to for the transfer of | rendezvous point to direct HTTP requests to for the transfer of | |||
information. Examples include encoding of a prompt to retrieve in | information. Examples include encoding of a prompt to retrieve in | |||
the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target | the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target | |||
in a VoiceXML [W3C.REC-voicexml21-20070619] script. | in a VoiceXML [W3C.REC-voicexml21-20070619] script. | |||
8. Syntax | 8. Syntax | |||
8.1. General | 8.1. General | |||
This Section describes the syntax extensions required for the INFO | This section describes the syntax extensions required for the INFO | |||
method. The previous sections describe the semantics. Note the | method. The previous sections describe the semantics. Note the | |||
formal syntax definitions described in this document use the ABNF | formal syntax definitions described in this document use the ABNF | |||
format used in [RFC3261] and contain references to elements defined | format used in [RFC3261] and contain references to elements defined | |||
therein. | therein. | |||
8.2. ABNF | 8.2. ABNF | |||
INFOm = %x49.4E.46.4F ; INFO in caps | INFOm = %x49.4E.46.4F ; INFO in caps | |||
extension-method = INFOm / token | extension-method = INFOm / token | |||
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 = "nil" | Info-package-list = Info-package-type *( COMMA Info-package-type ) | |||
/ Info-package-type *( COMMA Info-package-type ) | Info-package-type = Info-package-name *( SEMI Info-package-param) | |||
Info-package-type = Info-package-name *( ";" Info-package-param) | ||||
Info-package-name = token | Info-package-name = token | |||
Info-package-param = generic-param | Info-package-param = generic-param | |||
NOTE on the Recv-Info production: if the header field value is "nil", | ||||
the header field MUST NOT contain any other Info Packages, and the | ||||
SIP message MUST NOT contain more than one Recv-Info header field. | ||||
9. Legacy INFO Usage | 9. Legacy INFO Usage | |||
9.1. General | 9.1. General | |||
A number of applications, standardized and proprietary, make use of | A number of applications, standardized and proprietary, make use of | |||
the INFO method as it was previously defined in [RFC2976], referred | the INFO method as it was previously defined in [RFC2976], referred | |||
to as "legacy INFO usage". | to as "legacy INFO usage". | |||
For backward compatibility purpose, this document does not deprecate | For backward compatibility purpose, this document does not deprecate | |||
such usages, and does not mandate users to define Info Packages for | such usages, and does not mandate users to define Info Packages for | |||
skipping to change at page 18, line 44 | skipping to change at page 19, line 27 | |||
static configuration about for what type of applications and contexts | static configuration about for what type of applications and contexts | |||
UAs support the INFO method, and the way they handle application | UAs support the INFO method, and the way they handle application | |||
information transported in INFO messages. That has caused | information transported in INFO messages. That has caused | |||
interoperability problems in the industry. Therefore, a need for a | interoperability problems in the industry. Therefore, a need for a | |||
well defined and documented description of what the information sent | well defined and documented description of what the information sent | |||
in the INFO is used for has been identified. This situation is | in the INFO is used for has been identified. This situation is | |||
analogous to the context issue in Internet Mail [RFC3458]. | analogous to the context issue in Internet Mail [RFC3458]. | |||
9.3. Co-existence with Info Package based INFO usage | 9.3. Co-existence with Info Package based INFO usage | |||
As described in Section 4, an INFO request associated with an Info | As described in Section 3, an INFO request associated with an Info | |||
Package always contains an Info-Package header field. A legacy INFO | Package always contains an Info-Package header field. A UA MUST NOT | |||
request MUST NOT contain an Info-Package header field. | insert an Info-Package header field in a legacy INFO request. | |||
UAs are allowed to enable both legacy INFO usages and Info Package | UAs are allowed to enable both legacy INFO usages and Info Package | |||
usages as part of the same invite dialog usage. | usages as part of the same invite dialog usage. | |||
See Appendix A for examples of existing legacy INFO usages. | See Appendix A for examples of existing legacy INFO usages. | |||
10. Info Package Requirements | 10. Info Package Requirements | |||
10.1. General | 10.1. General | |||
This Section provides guidance on how to define an Info Package, and | This section provides guidance on how to define an Info Package, and | |||
what information needs to be provided. | what information needs to exist in an Info Package specification. | |||
If an Info Package extends or modifies the behavior described in this | If, for an Info Package, there is a need to extend or modify the | |||
document, it MUST be described in the definition for that Info | behavior described in this document, that behaviour MUST be described | |||
Package. Info Package definitions should not repeat procedures | in the Info Package specification. It is bad practice for Info | |||
defined in this specification, unless needed for clarification or | Package specifications to repeat procedures defined in this document, | |||
emphasis purpose. | unless needed for clarification or emphasis purpose. | |||
Info Packages MUST NOT weaken any behavior designated with "SHOULD" | Info Package specifications MUST NOT weaken any behavior designated | |||
or "MUST" in this specification. However, Info Packages MAY | with "SHOULD" or "MUST" in this specification. However, Info | |||
strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" | Packages specifications MAY strengthen "SHOULD", "MAY", or | |||
strength if applications associated with the Info Package requires | "RECOMMENDED" requirements to "MUST" strength if applications | |||
it. | associated with the Info Package requires it. | |||
Info Package definitions SHALL address the issues defined in the | Info Package specifications MUST address the issues defined in the | |||
following subsections, or document why an issue is not applicable for | following subsections, or document why an issue is not applicable for | |||
the specific Info Package. | the specific Info Package. | |||
10.2. Applicability | Section 7.4 describes alternative mechanisms, which should be | |||
considered as part of the process for solving a specific use-case, | ||||
when for transporting application information. | ||||
10.2. Overal Description | ||||
The Info Package specification MUST contain an overlap description of | ||||
the Info Package: what type of information are carried in INFO | ||||
requests associated with the Info Package, and for what type of | ||||
applications and functionalities UAs can use the Info Package. | ||||
If the Info Package is defined for a specific application, the Info | ||||
Package specification MUST state which application UAs can use the | ||||
Info Package with. | ||||
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 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 | Annex A provides more information, and describes alternative | |||
mechanisms which one should consider for solving a specific use-case. | mechanisms which one should consider for solving a specific use-case. | |||
10.3. Info Package Name | 10.4. Info Package Name | |||
The Info Package specification MUST define a for Info Package name | The Info Package specification MUST define an Info Package name, | |||
(e.g. "Info Package for X"). | which UAs use as a header field value (e.g. "infoX") to be identify | |||
the Info Package in the Recv-Info and Info-Package header fields. | ||||
The header field value MUST conform to the ABNF defined in | ||||
Section 8.2. | ||||
The specification MUST also define the header field value (e.g. | The Info Package mechanism does not support package versioning. | |||
"infoX") to be used to indicate support of this package in the Recv- | Specific Info Package message body payloads can contain version | |||
Info and Info-Package header fields. The header field value MUST | information, which is handled by the applications associated with the | |||
conform to the ABNF defined in Section 8.2. | Info Package. However, such feature is outside the scope of the | |||
generic Info Package mechanism. | ||||
The specification MUST also include the information that appears in | NOTE: Even if an Info Package name contains version numbering (e.g. | |||
the IANA registration of the token. For information on registering | foo_v2), the Info Package mechanism does not distinguish a version | |||
such types, see Section 9. | number from the rest of the Info Package name. | |||
10.4. Info Package Parameters | The IANA registration requirements for Info Package names are defined | |||
in Section 10.5. | ||||
The Info Package specification MAY define Info Package parameters | 10.5. 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 representing the Info Package. | together with the header field value which indicates the Info Package | |||
name (see Section 10.4. | ||||
The specification MUST describe the syntax and semantics of the | The Info Package specification MUST define the syntax and semantics | |||
parameters. It MUST be specified whether a specific parameter is | of the defined parameters. In addition, the specification MUST | |||
only applicable to the Recv-Info header, the Info-Package header, or | define whether a specific parameter is only applicable to the Recv- | |||
both. | Info header field, the Info-Package header field, or both. | |||
Note that Info Package parameters are only applicable for the Info | By default, an Info Package parameter is only applicable for the Info | |||
Package(s) for which they have been explicitly defined. They MUST | Package for which the parameter has been explicitly defined. | |||
NOT be used for other Info Packages. | ||||
NOTE: Info Package parameters defined for specific Info Packages may | NOTE: Info Package parameters defined for specific Info Packages can | |||
share the name with parameters defined for other Info Packages, but | share the name with parameters defined for other Info Packages, but | |||
the parameter semantics are specific to the Info Package for which | the parameter semantics are specific to the Info Package for which | |||
they are defined. | they are defined. | |||
10.5. SIP Option Tags | 10.6. SIP Option Tags | |||
The Info Package specification MAY define SIP option tags, which can | The Info Package specification MAY define SIP option tags, which can | |||
be used as described in [RFC3261]. | be used as described in [RFC3261]. | |||
SIP option tags MUST conform to the SIP Change Process | The registration requirements for option tags are defined in | |||
[I-D.peterson-rai-rfc3427bis]. | [I-D.peterson-rai-rfc3427bis]. | |||
10.6. INFO Message Bodies | 10.7. INFO Message Body Parts | |||
The Info Package specification MUST define what type of message body | The Info Package specification MUST define which message body part | |||
parts are associated with the Info Package, and MUST refer to | MIME types are associated with the Info Package. The specification | |||
specifications where the syntax, semantics and MIME type of the | MUST either define those body parts, which include the syntax, | |||
message body parts are described. | semantics and MIME type of the each body part, or refer to other | |||
documents which define the body parts. | ||||
If multiple body parts are used with an Info Package, the Info | If multiple message body part MIME types are associated with an Info | |||
Package specification MUST define whether there are special rules on | Package, the Info Package specification MUST define whether UAs need | |||
how the body parts are to be inserted in multipart body parts, and | to use multipart body parts in order to include multiple body parts | |||
what types of multipart to use. | in a single INFO request. | |||
10.7. Info Package Usage Restrictions | 10.8. Info Package Usage Restrictions | |||
The Info Package specification MUST define whether a UA is allowed to | If there are restrictions on how UAs can use an Info Package, the | |||
send overlapping (outstanding) INFO requests associated with the Info | Info Package specification MUST document such restrictions. | |||
There can be restrictions related to whether UAs are allowed to send | ||||
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. | |||
The specification MUST define whether there are SIP level | There can also be restrictions related to whether UAs need to support | |||
restrictions in the usage of the Info Package. For example, an Info | and use other SIP extensions and capabilities when they use the Info | |||
Package may require support of other SIP extensions (e.g. reliable | Package, and if there are restrictions related to how UAs can use the | |||
provisional responses). | Info-Package together with other Info Packages. | |||
The specification MUST define whether there are restrictions on | ||||
indicating support of, or using, the Info Package together with other | ||||
Info Packages. | ||||
As the SIP stack may 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.4, in most cases a 200 OK response | rejected. As defined in Section 3.2.2, UAs will normally send a 200 | |||
will be sent for the INFO request. The application logic associated | (OK) response to an INFO request. The application logic associated | |||
with the Info Package needs to handle situations which can occur due | with the Info Package needs to handle situations where UAs do not | |||
to overlapping requests. | follow restrictions associated with the Info Package. | |||
10.8. Rate of INFO Requests | ||||
The Info Package specification MUST specify a maximum rate at which | ||||
INFO requests associated with the specific Info Package can be | ||||
generated by a UA in a dialog. | ||||
The specification MAY define Info Package parameters to be used for | 10.9. Rate of INFO Requests | |||
indicating or negotiating the INFO request rate. Alternatively the | ||||
rate information can be included in the application information | ||||
associated with the Info Package. | ||||
10.9. IANA Registrations | If there is a maximum or minumum rate at which UAs can send INFO | |||
requests associated with the Info Package within a dialog, the Info | ||||
Package specification MUST document the rate values. | ||||
The Info Package specification MUST contain an IANA Considerations | If the rates can vary, the Info Package specification MAY define Info | |||
section that includes definitions for the Info Package Name and, if | Package parameters that UAs can use to indicate or negotiate the | |||
needed, supported MIME types. | rates. Alternatively the rate information can be part of the | |||
application data information associated with the Info Package. | ||||
10.10. Info Package Security Considerations | 10.10. Info Package Security Considerations | |||
If the application information associated with the Info Package | If the application information carried in INFO requests associated | |||
requires certain level of security, the Info Package specification | with the Info Package requires certain level of security, the Info | |||
MUST describe the mechanisms to be used in order to provide the | Package specification MUST describe the mechanisms that UAs need to | |||
required security. | use in order to provide the required security. | |||
Otherwise, even if no additional security than what is provided for | If the Info Package specification does not require any additional | |||
the underlying SIP protocol is needed, this fact SHALL be stated in | security, other than what the underlying SIP protocol provides, it | |||
the Info Package specification. | MUST be stated in the Info Package specification. | |||
NOTE: In some cases, it may not be sufficient to mandate TLS in order | NOTE: In some cases, it may not be sufficient to mandate TLS in order | |||
to secure the Info Package payload, since intermediaries will have | to secure the Info Package payload, since intermediaries will have | |||
access to the payload, and beyond the first hop, there is no way to | access to the payload, and beyond the first hop, there is no way to | |||
assure subsequent hops will not forwards the payload in clear text. | assure subsequent hops will not forwards the payload in clear text. | |||
The best way to ensure secure transport at the application level is | The best way to ensure secure transport at the application level is | |||
to have the security at the application level. One way of achieving | to have the security at the application level. One way of achieving | |||
this is to use end-to-end security techniques such as S/MIME | this is to use end-to-end security techniques such as S/MIME | |||
[RFC3851]. | [RFC3851]. | |||
10.11. Application Procedures | 10.11. Implementation Details | |||
The Info Package specification SHOULD contain a description of the | It is strongly RECOMMENDED that the Info Package specification | |||
application procedures associated with the Info Package, or | defines the procedure how implementors shall implement and use the | |||
alternatively refer to application procedures defined elsewhere. | Info Package, or refer to other locations where implementors can find | |||
that information. | ||||
NOTE: Sometimes Info Package designer might choose to not reveal the | ||||
details of an Info Package. However, in order to allow multiple | ||||
implementations to support the Info Package, Info Package designers | ||||
are stronly encouraged to provide the implementation details. | ||||
10.12. Examples | 10.12. Examples | |||
It is recommended that Info Package specifications include | It is RECOMMENDED that the Info Package specification provides | |||
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 | Please update the existing registration in the SIP Methods and | |||
Response Codes registry under the SIP Parameters registry that | Response Codes registry under the SIP Parameters registry that | |||
states: | states: | |||
Method: INFO | Method: INFO | |||
skipping to change at page 23, line 21 | skipping to change at page 24, line 29 | |||
Please add the following new SIP header field in the Header Fields | Please add the following new SIP header field in the Header Fields | |||
subregistry under the SIP Parameters registry. | subregistry under the SIP Parameters registry. | |||
Header Name: Recv-Info | Header Name: Recv-Info | |||
Compact Form: (none) | Compact Form: (none) | |||
Reference: [RFCXXXX] | Reference: [RFCXXXX] | |||
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 | Please create a subregistry in the SIP Parameters registry for Info | |||
Packages. This subregistry has a modified First Come First Served | Packages. | |||
[RFC5226] policy. | ||||
Based on [RFC5226], IANA assigns an expert in order to review an Info | ||||
Package which is to be registered. The Info Package specification is | ||||
provided to the reviewer, who ensures that the Info Package is | ||||
described in a proper way. | ||||
The reviewer does not consider the applicability of the Info Package | ||||
for the usage for which it is defined. | ||||
The following data elements populate the Info Package Registry. | The following data elements populate the Info Package Registry. | |||
o Info Package Name: The Info Package Name is a case-sensitive | o Info Package Name: The Info Package Name is a case insensitive | |||
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 Info Package Parameters: The Info Package Parameters are case- | o Reference: A reference to a specification which describes the Info | |||
sensitive tokens. Info Package Parameters are only applicable to | Package. | |||
the Info Package for which they are defined, so the same Info | ||||
Package Parameter Names may exist for different Info Packages. | ||||
o Info Package Payload MIME Types: A list of zero or more registered | ||||
MIME types from the MIME Type Registry. | ||||
o Standards Status: Values are "Standards Track" or empty. See | ||||
below for a discussion and rules on this field. | ||||
o Reference: If there is a published specification describing the | ||||
Info Package, place a reference to that specification in this | ||||
column. See below for a discussion on this field. | ||||
If there is a published specification, the registration must include | ||||
a reference to such specification. The Standards Status field is an | ||||
indicator of the level of community review for the Info Package | ||||
specification. If the specification meets the requirements for | ||||
Specification Required [RFC5226], the value for the Standards Status | ||||
field is "Standards Track". Otherwise, the field is empty. | ||||
This document uses the Info Package Name "nil" to represent "no Info | ||||
Package present" and as such, IANA shall not honor a request to | ||||
register the "nil" Info Package. | ||||
The initial population of this table shall be: | The initial population of this table shall be: | |||
Name MIME Type Standards Status Reference | Name Reference | |||
nil Standards Track [RFCXXXX] | ||||
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- | Please add the following new header field value to the Content- | |||
Disposition registry. | Disposition registry. | |||
Name: info-package | Name: info-package | |||
Description: the body contains information associated with an Info Package | Description: the body contains information associated with an Info Package | |||
Reference: RFCXXXX | Reference: RFCXXXX | |||
11.6. SIP Response Code 469 Registration | 11.6. SIP Response Code 469 Registration | |||
Please register the following new response code in the Session | Please register the following new response code in the Session | |||
Initiation Protocol Parameters - Response Codes registry. | Initiation Protocol Parameters - Response Codes registry. | |||
Response Code: 469 | Response Code: 469 | |||
Default Reason Phrase: Bad INFO Package | Default Reason Phrase: Bad INFO Package | |||
Reference: RFCXXXX | Reference: RFCXXXX | |||
12. Examples | 12. Examples | |||
12.1. Indication of which Info Packages UAs are willing to receive INFO | 12.1. Indication for which Info Packages UAs are willing to receive | |||
requests within an invite dialog usage | INFO requests | |||
The UAC sends an INVITE request, where the UAC indicates that it is | 12.1.1. Initial INVITE request | |||
willing to receive Info Packages P and R. | ||||
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. | ||||
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 | |||
CSeq: 314159 INVITE | CSeq: 314159 INVITE | |||
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 Packages R and T. | indicates that it is willing to receive INFO requests for Info | |||
Packages R and T. | ||||
SIP/2.0 200 OK | SIP/2.0 200 OK | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 | Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 | |||
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 INVITE | CSeq: 314159 INVITE | |||
Contact: <sip:alice@pc33.example.com> | Contact: <sip:bob@pc33.example.com> | |||
Recv-Info: R, T | Recv-Info: R, T | |||
Content-Type: application/sdp | Content-Type: application/sdp | |||
Content-Length: ... | Content-Length: ... | |||
... | ... | |||
The UAC sends ACK. | The UAC sends an ACK request. | |||
ACK sip:ngw1@a.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.2. INFO request with information associated with a simple Info | 12.1.2. Target refresh | |||
Package | ||||
Here Alice sends Bob a simple Info Package payload. | 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 | ||||
not willing to receive INFO requests for any Info Packages. | ||||
INFO sip:alice@192.0.2.1 SIP/2.0 | UPDATE sip:bob@pc33.example.com SIP/2.0 | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 | ||||
Max-Forwards: 70 | ||||
To: Bob <sip:bob@example.com>;tag=a6c85cf | ||||
From: Alice <sip:alice@example.com>;tag=1928301774 | ||||
Call-ID: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314163 UPDATE | ||||
Recv-Info: | ||||
Contact: <sip:alice@pc33.example.com> | ||||
Content-Type: application/sdp | ||||
Content-Length: ... | ||||
... | ||||
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 | ||||
Packages R. | ||||
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 | ||||
The UA sends an INFO request associated with Info Package foo. | ||||
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: Bob <sip:bob@example.com>;tag=a6c85cf | |||
From: Bob <sip:bob@example.com>;tag=abcdefg | From: Alice <sip:alice@example.com>;tag=1928301774 | |||
Call-Id: 123456mcmxcix | Call-Id: a84b4c76e66710@pc33.example.com | |||
CSeq: 2 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.3. Multipart INFO Example | 12.2.2. Multipart INFO | |||
Other SIP extensions can sometimes add payload body parts into an | 12.2.2.1. Non-Info Package body part | |||
INFO request, independent of the Info Package. In this case, the | ||||
Info Package payload gets put into a Multipart MIME body, with a | ||||
Content-Disposition header field that indicates which body part is | ||||
associated with the Info Package. | ||||
INFO sip:alice@192.0.2.1 SIP/2.0 | SIP extensions can sometimes add body part payloads into an INFO | |||
request, independent of the Info Package. In this case, the Info | ||||
Package payload gets put into a Multipart MIME body, with a Content- | ||||
Disposition header field that indicates which body part is associated | ||||
with the Info Package. | ||||
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: 123456mcmxcix | Call-Id: a84b4c76e66710@pc33.example.com | |||
CSeq: 7 INFO | CSeq: 314400 INFO | |||
Info-Package: foo | Info-Package: foo | |||
mumble-extension: <cid:abcd9999qq> | ||||
Content-Type: multipart/mixed;boundary="theboundary" | Content-Type: multipart/mixed;boundary="theboundary" | |||
Content-Length: ... | Content-Length: ... | |||
--theboundary | --theboundary | |||
Content-Type: application/mumble | Content-Type: application/mumble | |||
Content-Id: abcd9999qq | ||||
... | ... | |||
<mumble stuff> | <mumble stuff> | |||
--theboundary | --theboundary | |||
Content-Type: application/foo | Content-Type: application/foo-x | |||
Content-Disposition: Info-Package | Content-Disposition: Info-Package | |||
Content-length: 24 | Content-length: 59 | |||
I am a foo message type | I am a foo-x message type, and I belong to Info Package foo | |||
--theboundary-- | ||||
12.2.2.2. Info Package with multiple body parts inside multipart body | ||||
part | ||||
Multiple body part payloads can be associated with a single Info | ||||
Package. In this case, the body parts are put into a Multipart MIME | ||||
body, with a Content-Disposition header field that indicates which | ||||
body part is associated with the Info Package. | ||||
INFO sip:alice@pc33.example.com SIP/2.0 | ||||
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | ||||
To: Alice <sip:alice@example.net>;tag=1234567 | ||||
From: Bob <sip:bob@example.com>;tag=abcdefg | ||||
Call-Id: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314423 INFO | ||||
Info-Package: foo | ||||
Content-Type: multipart/mixed;boundary="theboundary" | ||||
Content-Disposition: Info-Package | ||||
Content-Length: ... | ||||
--theboundary | ||||
Content-Type: application/foo-x | ||||
Content-length: 59 | ||||
I am a foo-x message type, and I belong to Info Package foo | ||||
<mumble stuff> | ||||
--theboundary | ||||
Content-Type: application/foo-y | ||||
Content-length: 59 | ||||
I am a foo-y message type, and I belong to Info Package foo | ||||
--theboundary-- | ||||
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 | ||||
Content-Disposition header field value other than "Info-Package". In | ||||
this case, the body part is put into a Multipart MIME body, with a | ||||
Content-Disposition header field that indicates which body part is | ||||
associated with the Info Package. | ||||
INFO sip:alice@pc33.example.com SIP/2.0 | ||||
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef | ||||
To: Alice <sip:alice@example.net>;tag=1234567 | ||||
From: Bob <sip:bob@example.com>;tag=abcdefg | ||||
Call-Id: a84b4c76e66710@pc33.example.com | ||||
CSeq: 314423 INFO | ||||
Info-Package: foo | ||||
Content-Type: multipart/mixed;boundary="theboundary" | ||||
Content-Disposition: Info-Package | ||||
Content-Length: ... | ||||
--theboundary | ||||
Content-Type: application/foo-x | ||||
Content-Disposition: icon | ||||
Content-length: 59 | ||||
I am a foo-x message type, and I belong to Info Package foo | ||||
--theboundary-- | --theboundary-- | |||
13. Security Considerations | 13. Security Considerations | |||
By eliminating multiple usages of INFO messages without adequate | By eliminating multiple usages of INFO messages without adequate | |||
community review and by eliminating the possibility for rogue SIP UAs | community review and by eliminating the possibility for rogue SIP UAs | |||
from confusing another UA by purposely sending unrelated INFO | from confusing another UA by purposely sending unrelated INFO | |||
requests, we expect this document's clarification of the use of INFO | requests, we expect this document's clarification of the use of INFO | |||
to improve the security of the Internet. Whilst rogue UAs can still | to improve the security of the Internet. Whilst rogue UAs can still | |||
send unrelated INFO requests, this mechanism provides mechanisms for | send unrelated INFO requests, this mechanism provides mechanisms for | |||
skipping to change at page 28, line 13 | skipping to change at page 31, line 46 | |||
Initiation Protocol (SIP)", RFC 5621, September 2009. | Initiation Protocol (SIP)", RFC 5621, September 2009. | |||
14.2. Informative References | 14.2. Informative References | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
RFC 793, September 1981. | RFC 793, September 1981. | |||
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, | [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, | |||
October 2000. | October 2000. | |||
[RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, | ||||
"Interworking between the Session Initiation Protocol | ||||
(SIP) and QSIG", BCP 117, RFC 4497, May 2006. | ||||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", | |||
RFC 4949, August 2007. | RFC 4949, August 2007. | |||
skipping to change at page 29, line 44 | skipping to change at page 33, line 27 | |||
September 2007. | September 2007. | |||
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session | [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session | |||
Initiation Protocol", RFC 5057, November 2007. | Initiation Protocol", RFC 5057, November 2007. | |||
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for | [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for | |||
Media Control", RFC 5168, March 2008. | Media Control", RFC 5168, March 2008. | |||
[I-D.peterson-rai-rfc3427bis] | [I-D.peterson-rai-rfc3427bis] | |||
Peterson, J., Jennings, C., and R. Sparks, "Change Process | Peterson, J., Jennings, C., and R. Sparks, "Change Process | |||
for the Session Initiation Protocol (SIP)", | for the Session Initiation Protocol (SIP) and the Real- | |||
draft-peterson-rai-rfc3427bis-03 (work in progress), | time Applications and Infrastructure Area", | |||
September 2009. | draft-peterson-rai-rfc3427bis-04 (work in progress), | |||
October 2009. | ||||
[W3C.REC-voicexml21-20070619] | [W3C.REC-voicexml21-20070619] | |||
McGlashan, S., Lee, A., Carter, J., Porter, B., Auburn, | Lee, A., Porter, B., Oshry, M., Burnett, D., Rehor, K., | |||
R., Oshry, M., Rehor, K., Bodell, M., Burke, D., Baggia, | Auburn, R., Bodell, M., Burke, D., Baggia, P., Candell, | |||
P., Candell, E., and D. Burnett, "Voice Extensible Markup | E., Carter, J., and S. McGlashan, "Voice Extensible Markup | |||
Language (VoiceXML) 2.1", World Wide Web Consortium | Language (VoiceXML) 2.1", World Wide Web Consortium | |||
Recommendation REC-voicexml21-20070619, June 2007, | Recommendation REC-voicexml21-20070619, June 2007, | |||
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>. | <http://www.w3.org/TR/2007/REC-voicexml21-20070619>. | |||
[I-D.ietf-speechsc-mrcpv2] | [I-D.ietf-speechsc-mrcpv2] | |||
Shanmugham, S. and D. Burnett, "Media Resource Control | Shanmugham, S. and D. Burnett, "Media Resource Control | |||
Protocol Version 2 (MRCPv2)", | Protocol Version 2 (MRCPv2)", | |||
draft-ietf-speechsc-mrcpv2-20 (work in progress), | draft-ietf-speechsc-mrcpv2-20 (work in progress), | |||
August 2009. | August 2009. | |||
skipping to change at page 30, line 24 | skipping to change at page 34, line 8 | |||
Saleem, A. and G. Sharratt, "Media Server Markup Language | Saleem, A. and G. Sharratt, "Media Server Markup Language | |||
(MSML)", draft-saleem-msml-09 (work in progress), | (MSML)", draft-saleem-msml-09 (work in progress), | |||
July 2009. | July 2009. | |||
[Ecma-355] | [Ecma-355] | |||
"Standard ECMA-355 Corporate Telecommunication Networks - | "Standard ECMA-355 Corporate Telecommunication Networks - | |||
Tunnelling of QSIG over SIP", ECMA http:// | Tunnelling of QSIG over SIP", ECMA http:// | |||
www.ecma-international.org/publications/standards/ | www.ecma-international.org/publications/standards/ | |||
Ecma-355.htm, June 2008. | Ecma-355.htm, June 2008. | |||
Appendix A. Legacy INFO Usages | Appendix A. Legacy INFO Usage | |||
A.1. General | A.1. General | |||
This section provides examples of existing legacy INFO usages. This | This section provides examples of existing legacy INFO usages. The | |||
section is not meant to be a comprehensive catalog of legacy INFO | section is not meant to be a comprehensive catalog of legacy INFO | |||
usages, but it should give the reader a flavor for current legacy | usages, but it should give the reader a flavor for current legacy | |||
INFO usages. | INFO usages. | |||
A.2. ISUP | A.2. ISUP | |||
[RFC3372] specifies the encapsulation of ISUP in SIP message bodies. | [RFC3372] specifies the encapsulation of ISUP in SIP message bodies. | |||
ITU-T and 3GPP have specified similar procedures. | ITU-T and 3GPP have specified similar procedures. | |||
A.3. QSIG | A.3. QSIG | |||
skipping to change at page 31, line 42 | skipping to change at page 35, line 24 | |||
Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael | Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael | |||
Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, | Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, | |||
Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore | Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore | |||
Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve | Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve | |||
Langstaff, Sumit Garg and Xavier Marjoum. | Langstaff, Sumit 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 Figure 1. | |||
John Elwell and Robert Sparks provided valuable feedback during the | Brett Tate, John Elwell, Keith Drage and Robert Sparks provided | |||
WGLC process, in order to prepare this document for publication. | valuable feedback during the WGLC process, in order to prepare this | |||
document for publication. | ||||
Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided | ||||
valuable input in order to sort out the message body part usage for | ||||
Info Packages. | ||||
Appendix C. Change Log | Appendix C. Change Log | |||
[RFC EDITOR NOTE: Please remove this section when publishing] | [RFC EDITOR NOTE: Please remove this section when publishing] | |||
Changes from draft-ietf-sipcore-info-events-02 | ||||
o Further changes based on WGLC comments | ||||
o Allignment 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 Clarifiaction 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 | Changes from draft-ietf-sipcore-info-events-01 | |||
o Further changes based on WGLC comments | o Further changes based on WGLC comments | |||
o Appending A moved into the main part of the document | o Appending A moved into the main part of the document | |||
o Section name changed from "Modifications to SIP Change Process" to | o Section name changed from "Modifications to SIP Change Process" to | |||
"Security Considerations" | "Security Considerations" | |||
o "Syntax" section moved further up in the document | o "Syntax" section moved further up in the document | |||
o Clarification on usage of Info Package related message body parts, | o Clarification on usage of Info Package related message body parts, | |||
and the usage of the Content-Disposition header field with those | and the usage of the Content-Disposition header field with those | |||
body parts | body parts | |||
o Removed REFER and NOTIFY from the INFO Headers table | o Removed REFER and NOTIFY from the INFO Headers table | |||
End of changes. 171 change blocks. | ||||
539 lines changed or deleted | 700 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |