draft-ietf-sipcore-info-events-03.txt | draft-ietf-sipcore-info-events-04.txt | |||
---|---|---|---|---|
SIPCORE E. Burger | SIPCORE C. Holmberg | |||
Internet-Draft NeuStar, Inc. | Internet-Draft Ericsson | |||
Obsoletes: RFC 2976 H. Kaplan | Obsoletes: RFC 2976 E. Burger | |||
(if approved) Acme Packet | (if approved) NeuStar, Inc. | |||
Expires: June 5, 2010 C. Holmberg | Intended status: Standards Track H. Kaplan | |||
Ericsson | Expires: July 18, 2010 Acme Packet | |||
December 2, 2009 | January 14, 2010 | |||
Session Initiation Protocol (SIP) INFO Method and Package Framework | Session Initiation Protocol (SIP) INFO Method and Package Framework | |||
draft-ietf-sipcore-info-events-03 | draft-ietf-sipcore-info-events-04 | |||
Abstract | Abstract | |||
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. | |||
skipping to change at page 2, line 6 | 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 June 5, 2010. | This Internet-Draft will expire on July 18, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the BSD License. | described in the BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 | 3.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 | 3.2.1. INFO Request Sender . . . . . . . . . . . . . . . . . 6 | |||
3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 | 3.2.2. INFO Request Receiver . . . . . . . . . . . . . . . . 7 | |||
3.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . . 8 | ||||
3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 | 3.3. INFO Message Body . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 | 3.3.1. INFO Request Message Body . . . . . . . . . . . . . . 8 | |||
3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 | 3.3.2. INFO Response Message Body . . . . . . . . . . . . . . 8 | |||
3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 | 3.4. Order of Delivery . . . . . . . . . . . . . . . . . . . . 8 | |||
4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4. Info Packages . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 | 4.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 9 | |||
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 | 4.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . . 9 | |||
4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 | 4.2.3. Recv-Info header field rules . . . . . . . . . . . . . 11 | |||
4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 | 4.2.4. Info Package fallback rules . . . . . . . . . . . . . 11 | |||
4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 | 4.3. REGISTER Processing . . . . . . . . . . . . . . . . . . . 12 | |||
4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12 | 4.4. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 12 | |||
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 | 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 12 | |||
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 | 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.2. Info-Package header field . . . . . . . . . . . . . . . . 14 | 6.2. Info-Package header field . . . . . . . . . . . . . . . . 15 | |||
6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 | 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 15 | |||
7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 | 7. Info Package Considerations . . . . . . . . . . . . . . . . . 15 | |||
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 | 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 15 | |||
7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 | 7.3. INFO Request Rate and Volume . . . . . . . . . . . . . . 15 | |||
7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 | 7.4. Alternative Mechanisms . . . . . . . . . . . . . . . . . 16 | |||
7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 | 7.4.1. Alternative SIP signaling plane mechanisms . . . . . . 16 | |||
7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 | 7.4.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 17 | |||
7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 | 7.4.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17 | |||
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
9.3. Co-existence with Info Package based INFO usage . . . . . 19 | 9.3. Co-existence with Info Package based INFO usage . . . . . 19 | |||
10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 | 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 | |||
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 | 10.2. Overal Description . . . . . . . . . . . . . . . . . . . 20 | |||
10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 | 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20 | 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 21 | |||
10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 | 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 | |||
10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 | 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 | |||
10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21 | 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 22 | |||
10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 | 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 | |||
10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 | 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 | |||
10.10. Info Package Security Considerations . . . . . . . . . . 22 | 10.10. Info Package Security Considerations . . . . . . . . . . 23 | |||
10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 | 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 | |||
10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 | |||
11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 | 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 | |||
11.2. Registration of the Info-Package Header Field . . . . . . 24 | 11.2. Registration of the Info-Package Header Field . . . . . . 24 | |||
11.3. Registration of the Recv-Info Header Field . . . . . . . 24 | 11.3. Registration of the Recv-Info Header Field . . . . . . . 24 | |||
11.4. Creation of the Info Packages Registry . . . . . . . . . 24 | 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 | |||
11.5. Registration of the Info-Package Content-Disposition . . 25 | 11.5. Registration of the Info-Package Content-Disposition . . 25 | |||
11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 | 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 | |||
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
12.1. Indication for which Info Packages UAs are willing to | 12.1. Indication for which Info Packages UAs are willing to | |||
receive INFO requests . . . . . . . . . . . . . . . . . . 25 | receive INFO requests . . . . . . . . . . . . . . . . . . 25 | |||
12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 | 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 | |||
12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 | 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 | |||
12.2. INFO request associated with Info Package . . . . . . . . 27 | 12.2. INFO request associated with Info Package . . . . . . . . 27 | |||
12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 | 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 | |||
12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27 | 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 28 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 | 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 31 | 14.2. Informative References . . . . . . . . . . . . . . . . . 32 | |||
Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34 | Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 35 | |||
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34 | A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 | A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 35 | |||
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 | Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35 | |||
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 | Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
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 | |||
skipping to change at page 5, line 46 | skipping to change at page 5, line 46 | |||
NOTE: A UA can use an empty Recv-Info header field (a header field | NOTE: A UA can use an empty Recv-Info header field (a header field | |||
without a value) to indicate that it is not willing to receive INFO | without a value) to indicate that it is not willing to receive INFO | |||
requests for any Info-Package, but to inform other UAs that it still | requests for any Info-Package, but to inform other UAs that it still | |||
supports the Info Package mechanism. | supports the Info Package mechanism. | |||
When a UA sends an INFO request, it uses the Info-Package header | When a UA sends an INFO request, it uses the Info-Package header | |||
field to indicate which Info Package is associated with the request. | field to indicate which Info Package is associated with the request. | |||
One particular INFO request can only be associated with a single Info | One particular INFO request can only be associated with a single Info | |||
Package. | Package. | |||
This document obsoletes [RFC2976]. However, for backward | ||||
compatibility it 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. | ||||
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. The INFO Method | 3. The INFO Method | |||
skipping to change at page 6, line 30 | skipping to change at page 6, line 23 | |||
A gives more details on the types of applications for which the use | A gives more details on the types of applications for which the use | |||
of INFO is appropriate. | of INFO is appropriate. | |||
This section describes how a UA handles INFO requests and responses, | This section describes how a UA handles INFO requests and responses, | |||
as well as the message bodies included in INFO messages. | as well as the message bodies included in INFO messages. | |||
3.2. INFO Request | 3.2. INFO Request | |||
3.2.1. INFO Request Sender | 3.2.1. INFO Request Sender | |||
An INFO request can be associated with an Info Package (see X), or | An INFO request can be associated with an Info Package (see | |||
associated with a legacy INFO usage (see Y). | Section 4), or associated with a legacy INFO usage (see Section 9). | |||
The construction of the INFO request is the same as any other request | The construction of the INFO request is the same as any other non- | |||
within an existing invite dialog usage. A UA can send INFO requests | target refresh request within an existing invite dialog usage as | |||
both within early and confirmed dialogs. | described in Section 12.2 of [RFC3261]. | |||
When a UA sends an INFO request associated with an Info Package, it | When a UA sends an INFO request associated with an Info Package, it | |||
MUST include an Info-Package header field that indicates which Info | MUST include an Info-Package header field that indicates which Info | |||
Package is associated with the request. A specific INFO request can | Package is associated with the request. A specific INFO request can | |||
be used only for a single Info Package. | be used only for a single Info Package. | |||
When a UA sends an INFO request associated with an legacy INFO usage | When a UA sends an INFO request associated with an legacy INFO usage | |||
there is no Info Package associated with the request, and the UA MUST | there is no Info Package associated with the request, and the UA MUST | |||
NOT include an Info-Package header field in the request. | NOT include an Info-Package header field in the request. | |||
The INFO request MUST NOT contain a Recv-Info header field. A UA can | The INFO request MUST NOT contain a Recv-Info header field. A UA can | |||
only indicate a set of Info Packages for which it is willing to | only indicate a set of Info Packages for which it is willing to | |||
receive INFO requests by using the SIP methods (and their responses) | receive INFO requests by using the SIP methods (and their responses) | |||
listed in Section 4. | listed in Section 4. | |||
A UA MUST NOT use the INFO method outside an invite dialog usage. | A UA MUST NOT send an INFO request outside an invite dialog usage and | |||
MUST NOT send an INFO request for an Info Package inside an invite | ||||
UAs indicate, per-dialog basis, for which Info Packages they are | dialog usage if the remote UA has not indicated willingness to | |||
willing to receive INFO requests. The set of Info Packages cannot | receive that Info-Package within that dialog. | |||
automatically be used within other dialogs. | ||||
If a UA receives a 469 (Bad INFO Package) response to an INFO | If a UA receives a 469 (Bad INFO Package) response to an INFO | |||
request, based on [RFC5057] the response represents a Transaction | request, based on [RFC5057] the response represents a Transaction | |||
Only failure, and the UA MUST NOT terminate the invite dialog usage. | Only failure, and the UA MUST NOT terminate the invite dialog usage. | |||
Due to the possibility of forking, the UA whichs sends the initial | Due to the possibility of forking, the UA whichs sends the initial | |||
INVITE reqest MUST be prepared to receive INFO requests from multiple | INVITE reqest MUST be prepared to receive INFO requests from multiple | |||
remote UAs during the early dialog phase. In addition, the UA MUST | remote UAs during the early dialog phase. In addition, the UA MUST | |||
be prepared to receive different Recv-Info header field values from | be prepared to receive different Recv-Info header field values from | |||
different remote UAs. | different remote UAs. | |||
skipping to change at page 7, line 37 | skipping to change at page 7, line 30 | |||
3.2.2. INFO Request Receiver | 3.2.2. INFO Request Receiver | |||
If a UA receives an INFO request associated with an Info Package that | If a UA receives an INFO request associated with an Info Package that | |||
the UA has not indicated willingness to receive, the UA MUST send a | the UA has not indicated willingness to receive, the UA MUST send a | |||
469 (Bad INFO Package) response (see Section 11.6). In the | 469 (Bad INFO Package) response (see Section 11.6). In the | |||
terminology of Multiple Dialog Usages [RFC5057], this represents a | terminology of Multiple Dialog Usages [RFC5057], this represents a | |||
Transaction Only failure, and does not terminate the invite dialog | Transaction Only failure, and does not terminate the invite dialog | |||
usage. | usage. | |||
If a UA receives an INFO request associated with an Info Package, and | If a UA receives an INFO request associated with an Info Package and | |||
the message body part associated with the Info Package contains a | the message body part with Content-Disposition 'Info-Package' (see | |||
message body MIME type that the UA support, but which usage is not | Section 3.3.1) has a MIME type that the UA supports but not in the | |||
defined for the specific Info Package, it is RECOMMENDED that the UA | context of that Info Package, it is RECOMMENDED that the UA send a | |||
sends a 415 (Unsupported Media Type) response. | 415 (Unsupported Media Type) response. | |||
The UA MAY send other error responses, such as Request Failure (4xx), | The UA MAY send other error responses, such as Request Failure (4xx), | |||
Server Failure (5xx) and Global Failure (6xx), in accordance with the | Server Failure (5xx) and Global Failure (6xx), in accordance with the | |||
error handling procedures in [RFC3261]. | error handling procedures in [RFC3261]. | |||
Otherwise, if the INFO request is syntactically correct and well | Otherwise, if the INFO request is syntactically correct and well | |||
structured, the UA MUST send a 200 (OK) response. | structured, the UA MUST send a 200 (OK) response. | |||
NOTE: If the application needs to reject the information which it | NOTE: If the application needs to reject the information which it | |||
received in an INFO request, that needs to be done on the application | received in an INFO request, that needs to be done on the application | |||
level. Ie the application needs to trigger a new INFO request, which | level. Ie the application needs to trigger a new INFO request, which | |||
contains information that the previously received application data | contains information that the previously received application data | |||
was not accepted. Individual Info Package specifications need to | was not accepted. Individual Info Package specifications need to | |||
describe the details for such procedures. | describe the details for such procedures. | |||
3.2.3. SIP Proxies | ||||
Proxies need no additional behavior beyond that described in | ||||
[RFC3261] to support INFO. | ||||
3.3. INFO Message Body | 3.3. INFO Message Body | |||
3.3.1. INFO Request Message Body | 3.3.1. INFO Request Message Body | |||
The purpose of the INFO request is to carry application level | The purpose of the INFO request is to carry application level | |||
information between SIP UAs. The application information data is | information between SIP UAs. The application information data is | |||
carried in the payload of the message body of the INFO request. | carried in the payload of the message body of the INFO request. | |||
NOTE: An INFO request assocated with an Info Package can also include | NOTE: An INFO request assocated with an Info Package can also include | |||
information associated with the Info Package using Info-Package | information associated with the Info Package using Info-Package | |||
header field parameters. | header field parameters. | |||
If an INFO request associated with an Info Package contains a message | If an INFO request associated with an Info Package contains a message | |||
body part, the body part is identified by a Content-Disposition | body part, the body part is identified by a Content-Disposition | |||
header field 'Info-Package' value. The body part can contain a | header field 'Info-Package' value. The body part can contain a | |||
single MIME type, or it can be a multipart [RFC5621] which contains | single MIME type, or it can be a multipart [RFC5621] which contains | |||
other body parts associated with the Info Package. | other body parts associated with the Info Package. | |||
UAs MUST conform to [RFC5621] to support multipart body parts. | UAs MUST support multipart body parts in accordance with [RFC5621]. | |||
NOTE: Some SIP functions that are orthogonal to INFO can insert body | NOTE: An INFO request can also contain other body parts that are | |||
parts unrelated to the Info Package. | meaningful within the context of an invite dialog usage but are not | |||
specifically associated with the INFO method and the application | ||||
concerned. | ||||
When a UA supports a specific Info-Package, the UA also support all | When a UA supports a specific Info-Package, the UA also support all | |||
message body MIME types associated with that Info-Package. However, | message body MIME types associated with that Info-Package. However, | |||
in accordance with [RFC3261] the UA still indicates the supported | in accordance with [RFC3261] the UA still indicates the supported | |||
MIME types using the Accept header. | MIME types using the Accept header. | |||
3.3.2. INFO Response Message Body | 3.3.2. INFO Response Message Body | |||
A UA MUST NOT include a message body associated with an Info Package | A UA MUST NOT include a message body associated with an Info Package | |||
in an INFO response. Message bodies associated with Info Packages | in an INFO response. Message bodies associated with Info Packages | |||
skipping to change at page 9, line 33 | skipping to change at page 9, line 36 | |||
This section describes how a UA handles Info Packages, how a UA uses | This section describes how a UA handles Info Packages, how a UA uses | |||
the Recv-Info header field, and how the UA acts in re-INVITE rollback | the Recv-Info header field, and how the UA acts in re-INVITE rollback | |||
situations. | situations. | |||
4.2.2. UA Procedures | 4.2.2. UA Procedures | |||
A UA which supports the Info Package mechanism MUST indicate, using | A UA which supports the Info Package mechanism MUST indicate, using | |||
the Revc-Info header field, the set of Info Packages for which it is | 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 | willing to receive INFO requests. A UA can list multiple Info | |||
Packages in a single Recv-Info header field, and the UA can use | 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 | multiple Recv-Info header fields. A UA can use an empty Recv-Info | |||
field, ie a header field without any header field values. | header field, ie a header field without any header field values. | |||
A UA provides its set of Info Packages for which it is willing to | A UA provides its set of Info Packages for which it is willing to | |||
receive INFO requests during the dialog establishment. A UA can | receive INFO requests during the dialog establishment. A UA can | |||
update the set of Info Packages during the invite dialog usage. | update the set of Info Packages during the invite dialog usage. | |||
If a UA is not willing to receive INFO requests for any Info | If a UA is not willing to receive INFO requests for any Info | |||
Packages, during dialog establishment or later during the invite | Packages, during dialog establishment or later during the invite | |||
dialog usage, the UA MUST indicate this by including an empty Recv- | dialog usage, the UA MUST indicate this by including an empty Recv- | |||
Info header field. This informs other UAs that the UA still supports | Info header field. This informs other UAs that the UA still supports | |||
the Info Package mechanism. | the Info Package mechanism. | |||
skipping to change at page 10, line 30 | skipping to change at page 10, line 33 | |||
NOTE: When a UA sends a message which contains a Recv-Info header | NOTE: When a UA sends a message which contains a Recv-Info header | |||
field with a new set of Info Packages for which the UA is willing to | field with a new set of Info Packages for which the UA is willing to | |||
receive INFO requests the remote UA might, before it receives the | receive INFO requests the remote UA might, before it receives the | |||
message, send an INFO request based on the old set of Info Packages. | message, send an INFO request based on the old set of Info Packages. | |||
In this case the receiver of the INFO requests rejects, and sends a | In this case the receiver of the INFO requests rejects, and sends a | |||
469 (Bad INFO Package) response to, the INFO request. | 469 (Bad INFO Package) response to, the INFO request. | |||
If a UA indicates multiple Info Packages, which provide similar | If a UA indicates multiple Info Packages, which provide similar | |||
functionality, it is not possible to indicate a priority order of the | functionality, it is not possible to indicate a priority order of the | |||
Info Packages, or that that the UA wishes to only receive INFO | Info Packages, or to indicate that the UA wishes to only receive INFO | |||
request for one of the Info Packages. It is up to the application | requests for one of the Info Packages. It is up to the application | |||
logic associated with the Info Packages, and specific Info Package | logic associated with the Info Packages, and specific Info Package | |||
specifications, to describe application behavior in such cases. | specifications, to describe application behavior in such cases. | |||
For backward compatibility purpose, even if a UA indicates support of | For backward compatibility purpose, even if a UA indicates support of | |||
the Info Package mechanism, it is still allowed to enable legacy INFO | the Info Package mechanism, it is still allowed to enable legacy INFO | |||
usages Appendix A. In addition, if a UA indicates support of the | usages Appendix A. In addition, if a UA indicates support of the | |||
INFO method using the Allow header field [RFC3261], it does not | INFO method using the Allow header field [RFC3261], it does not | |||
implicitly indicate support of the Info Package mechanism. A UA MUST | implicitly indicate support of the Info Package mechanism. A UA MUST | |||
use the Recv-Info header field in order to indicate that it supports | 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- | the Info Package mechanism. Likewise, even if a UA uses the Recv- | |||
skipping to change at page 13, line 30 | skipping to change at page 13, line 30 | |||
From c m | From c m | |||
Geolocation R o | Geolocation R o | |||
Geolocation-Error r o | Geolocation-Error r o | |||
Max-Breadth R - | Max-Breadth R - | |||
Max-Forwards R o | Max-Forwards R o | |||
MIME-Version o | MIME-Version o | |||
Min-Expires - | Min-Expires - | |||
Organization - | Organization - | |||
Priority R - | Priority R - | |||
Privacy o | Privacy o | |||
Proxy-Authenticate 401 m | Proxy-Authenticate 401 o | |||
Proxy-Authenticate 407 o | Proxy-Authenticate 407 m | |||
Proxy-Authorization R o | Proxy-Authorization R o | |||
Proxy-Require R o | Proxy-Require R o | |||
Reason R o | Reason R o | |||
Record-Route R o | Record-Route R o | |||
Record-Route 2xx,18x o | Record-Route 2xx,18x o | |||
Referred-By R o | Referred-By R o | |||
Request-Disposition R o | Request-Disposition R o | |||
Require o | Require o | |||
Resource-Priority o | Resource-Priority o | |||
Retry-After R - | Retry-After R - | |||
skipping to change at page 14, line 22 | skipping to change at page 14, line 22 | |||
WWW-Authenticate 407 o | WWW-Authenticate 407 o | |||
Figure 1: Table 1: Summary of Header Fields | Figure 1: Table 1: Summary of Header Fields | |||
6. INFO Header Fields | 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 proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD | |||
Info-Package R - - - - - - - m* - - - - - | ------------------------------------------------------------------ | |||
Info-Package 469 - - - - - - - m* - - - - - | Info-Package R - - - - - - - m* - - | |||
Recv-Info R - - - m m o o - - o - - - | Info-Package 469 - - - - - - - m* - - | |||
Recv-Info 2xx - - - o** m - o***- - o***- - - | Recv-Info R - - - m m o o - - o | |||
Recv-Info 1xx - - - 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 | ||||
Header field where SUB NOT RFR | ||||
-------------------------------- | ||||
Info-Package R - - - | ||||
Info-Package 469 - - - | ||||
Recv-Info R - - - | ||||
Recv-Info 2xx - - - | ||||
Recv-Info 1xx - - - | ||||
Recv-Info r - - - | ||||
The support and usage of the Info-Package and Recv-Info header fields | The support and usage of the Info-Package and Recv-Info header fields | |||
is not applicalbe to UAs that only support legacy INFO usages. * Not | is not applicalbe to UAs that only support legacy INFO usages. * Not | |||
applicalbe to INFO requests and responses associated with legacy INFO | applicalbe to INFO requests and responses associated with legacy INFO | |||
usages. ** Mandatory in at least one reliable 18x/2xx response, if | usages. ** Mandatory in at least one reliable 18x/2xx response, if | |||
sent, to the INVITE request, if the associated INVITE request | sent, to the INVITE request, if the associated INVITE request | |||
contained a Recv-Info header field. *** Mandatory if the associated | contained a Recv-Info header field. *** Mandatory if the associated | |||
request contained a Recv-Info header field. | request contained a Recv-Info header field. | |||
Table 2: INFO-related Header Fields | Table 2: INFO-related Header Fields | |||
skipping to change at page 15, line 50 | skipping to change at page 16, line 14 | |||
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 media | |||
plane data transport mechanisms. | plane data transport mechanisms. | |||
7.4. Alternative Mechanisms | 7.4. Alternative Mechanisms | |||
7.4.1. Alternative SIP signaling plane mechanisms | 7.4.1. Alternative SIP signaling plane mechanisms | |||
7.4.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, | |||
skipping to change at page 17, line 19 | skipping to change at page 17, line 26 | |||
ser. | ser. | |||
7.4.2. Media Plane Mechanisms | 7.4.2. Media Plane Mechanisms | |||
7.4.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 intermediaries to examine the information, it | |||
information, it is recommended to use a media plane mechanism, rather | is recommended to use a media plane mechanism, rather than a SIP | |||
than a SIP signaling based. | signaling based. | |||
A low latency requirement for the exchange of information is one | A low latency requirement for the exchange of information is one | |||
strong indicator for using a media channel. Exchanging information | strong indicator for using a media channel. Exchanging information | |||
through the SIP routing network can introduce hundreds of | through the SIP routing network can introduce hundreds of | |||
milliseconds of latency. | milliseconds of latency. | |||
7.4.2.2. MRCPv2 | 7.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.4.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.4.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 a SIP-independent mechanism, such as | |||
such as HTTP [RFC2616]. In this model, the UA knows about a | HTTP [RFC2616]. In this model, the UA knows about a rendezvous point | |||
rendezvous point to direct HTTP requests to for the transfer of | to direct HTTP requests to for the transfer of information. Examples | |||
information. Examples include encoding of a prompt to retrieve in | include encoding of a prompt to retrieve in the SIP Request URI in | |||
the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target | [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- | |||
in a VoiceXML [W3C.REC-voicexml21-20070619] script. | 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, and for the Info-Package and Recv-Info header fields. The | |||
formal syntax definitions described in this document use the ABNF | previous sections describe the semantics. Note the formal syntax | |||
format used in [RFC3261] and contain references to elements defined | definitions described in this document use the ABNF format used in | |||
therein. | [RFC3261] and contain references to elements defined 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 = Info-package-type *( COMMA Info-package-type ) | Info-package-list = Info-package-type *( COMMA Info-package-type ) | |||
Info-package-type = Info-package-name *( SEMI Info-package-param) | Info-package-type = Info-package-name *( SEMI Info-package-param) | |||
skipping to change at page 20, line 6 | skipping to change at page 20, line 13 | |||
If, for an Info Package, there is a need to extend or modify the | If, for an Info Package, there is a need to extend or modify the | |||
behavior described in this document, that behaviour MUST be described | behavior described in this document, that behaviour MUST be described | |||
in the Info Package specification. It is bad practice for Info | in the Info Package specification. It is bad practice for Info | |||
Package specifications to repeat procedures defined in this document, | Package specifications to repeat procedures defined in this document, | |||
unless needed for clarification or emphasis purpose. | unless needed for clarification or emphasis purpose. | |||
Info Package specifications MUST NOT weaken any behavior designated | Info Package specifications MUST NOT weaken any behavior designated | |||
with "SHOULD" or "MUST" in this specification. However, Info | with "SHOULD" or "MUST" in this specification. However, Info | |||
Packages specifications MAY strengthen "SHOULD", "MAY", or | Packages specifications MAY strengthen "SHOULD", "MAY", or | |||
"RECOMMENDED" requirements to "MUST" strength if applications | "RECOMMENDED" requirements to "MUST" strength if applications | |||
associated with the Info Package requires it. | associated with the Info Package require it. | |||
Info Package specifications MUST address the issues defined in the | Info Package specifications MUST address the issues defined in the | |||
following subsections, or document why an issue is not applicable for | following subsections, or document why an issue is not applicable for | |||
the specific Info Package. | the specific Info Package. | |||
Section 7.4 describes alternative mechanisms, which should be | Section 7.4 describes alternative mechanisms, which should be | |||
considered as part of the process for solving a specific use-case, | considered as part of the process for solving a specific use-case, | |||
when for transporting application information. | when there is a need for transporting application information. | |||
10.2. Overal Description | 10.2. Overal Description | |||
The Info Package specification MUST contain an overlap description of | The Info Package specification MUST contain an overall description of | |||
the Info Package: what type of information are carried in INFO | the Info Package: what type of information are carried in INFO | |||
requests associated with the Info Package, and for what type of | requests associated with the Info Package, and for what type of | |||
applications and functionalities UAs can use the Info Package. | applications and functionalities UAs can use the Info Package. | |||
If the Info Package is defined for a specific application, the Info | If the Info Package is defined for a specific application, the Info | |||
Package specification MUST state which application UAs can use the | Package specification MUST state which application UAs can use the | |||
Info Package with. | Info Package with. | |||
10.3. Applicability | 10.3. Applicability | |||
skipping to change at page 20, line 45 | skipping to change at page 21, line 8 | |||
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.4. Info Package Name | 10.4. Info Package Name | |||
The Info Package specification MUST define an Info Package name, | The Info Package specification MUST define an Info Package name, | |||
which UAs use as a header field value (e.g. "infoX") to be identify | which UAs use as a header field value (e.g. "infoX") to identify the | |||
the Info Package in the Recv-Info and Info-Package header fields. | Info Package in the Recv-Info and Info-Package header fields. The | |||
The header field value MUST conform to the ABNF defined in | header field value MUST conform to the ABNF defined in Section 8.2. | |||
Section 8.2. | ||||
The Info Package mechanism does not support package versioning. | The Info Package mechanism does not support package versioning. | |||
Specific Info Package message body payloads can contain version | Specific Info Package message body payloads can contain version | |||
information, which is handled by the applications associated with the | information, which is handled by the applications associated with the | |||
Info Package. However, such feature is outside the scope of the | Info Package. However, such feature is outside the scope of the | |||
generic Info Package mechanism. | generic Info Package mechanism. | |||
NOTE: Even if an Info Package name contains version numbering (e.g. | NOTE: Even if an Info Package name contains version numbering (e.g. | |||
foo_v2), the Info Package mechanism does not distinguish a version | foo_v2), the Info Package mechanism does not distinguish a version | |||
number from the rest of the Info Package name. | number from the rest of the Info Package name. | |||
skipping to change at page 25, line 9 | skipping to change at page 25, line 13 | |||
Package. | Package. | |||
The initial population of this table shall be: | The initial population of this table shall be: | |||
Name Reference | Name Reference | |||
11.5. Registration of the Info-Package Content-Disposition | 11.5. Registration of the Info-Package Content-Disposition | |||
Please add the following new header field value to the Content- | 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 | |||
Reference: RFCXXXX | Info Package | |||
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 | |||
skipping to change at page 26, line 51 | skipping to change at page 27, line 21 | |||
CSeq: 314163 UPDATE | CSeq: 314163 UPDATE | |||
Recv-Info: | Recv-Info: | |||
Contact: <sip:alice@pc33.example.com> | Contact: <sip:alice@pc33.example.com> | |||
Content-Type: application/sdp | Content-Type: application/sdp | |||
Content-Length: ... | Content-Length: ... | |||
... | ... | |||
The UAS sends a 200 (OK) response back to the UAC, where the UAS | The UAS sends a 200 (OK) response back to the UAC, where the UAS | |||
indicates that it is willing to receive INFO requests for Info | indicates that it is willing to receive INFO requests for Info | |||
Packages R. | Packages R, T. | |||
SIP/2.0 200 OK | SIP/2.0 200 OK | |||
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 | Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;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: 314163 INVITE | CSeq: 314163 INVITE | |||
Contact: <sip:alice@pc33.example.com> | Contact: <sip:alice@pc33.example.com> | |||
Recv-Info: R, T | Recv-Info: R, T | |||
Content-Type: application/sdp | Content-Type: application/sdp | |||
Content-Length: ... | Content-Length: ... | |||
skipping to change at page 33, line 33 | skipping to change at page 34, line 33 | |||
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) and the Real- | for the Session Initiation Protocol (SIP) and the Real- | |||
time Applications and Infrastructure Area", | time Applications and Infrastructure Area", | |||
draft-peterson-rai-rfc3427bis-04 (work in progress), | draft-peterson-rai-rfc3427bis-04 (work in progress), | |||
October 2009. | October 2009. | |||
[W3C.REC-voicexml21-20070619] | [W3C.REC-voicexml21-20070619] | |||
Lee, A., Porter, B., Oshry, M., Burnett, D., Rehor, K., | Lee, A., Porter, B., McGlashan, S., Oshry, M., Auburn, R., | |||
Auburn, R., Bodell, M., Burke, D., Baggia, P., Candell, | Rehor, K., Bodell, M., Burke, D., Baggia, P., Candell, E., | |||
E., Carter, J., and S. McGlashan, "Voice Extensible Markup | Burnett, D., and J. Carter, "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 35, line 24 | skipping to change at page 36, 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. | |||
Brett Tate, John Elwell, Keith Drage and Robert Sparks provided | Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert | |||
valuable feedback during the WGLC process, in order to prepare this | Sparks provided valuable feedback during the WGLC process, in order | |||
document for publication. | to prepare this document for publication. | |||
Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided | Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided | |||
valuable input in order to sort out the message body part usage for | valuable input in order to sort out the message body part usage for | |||
Info Packages. | Info Packages. | |||
Appendix C. Change Log | Appendix C. Change Log | |||
[RFC EDITOR NOTE: Please remove this section when publishing] | [RFC EDITOR NOTE: Please remove this section when publishing] | |||
Changes from draft-ietf-sipcore-info-events-03 | ||||
o Further changes based on WGLC comments | ||||
o New section 3.2.3 added | ||||
Changes from draft-ietf-sipcore-info-events-02 | Changes from draft-ietf-sipcore-info-events-02 | |||
o Further changes based on WGLC comments | o Further changes based on WGLC comments | |||
o Allignment with "specification" and "definition" terminology | o Allignment with "specification" and "definition" terminology | |||
o Location switch of sections 3 and 4 | o Location switch of sections 3 and 4 | |||
o Corrections in header table | o Corrections in header table | |||
o IANA Info Package registration input changed | o IANA Info Package registration input changed | |||
o Clarifiaction regarding which SIP messages can contain the Recv- | o Clarifiaction regarding which SIP messages can contain the Recv- | |||
Info header field | Info header field | |||
o Recv-Info 'nil' value removed | o Recv-Info 'nil' value removed | |||
o Rules on usage of Recv-Info header clarified | o Rules on usage of Recv-Info header clarified | |||
skipping to change at page 37, line 45 | skipping to change at page 39, line 4 | |||
o Added Registrar behavior. | o Added Registrar behavior. | |||
o Added OPTIONS processing. | o Added OPTIONS processing. | |||
o Clarified overlapping INFO method processing. | o Clarified overlapping INFO method processing. | |||
o Described multiple INFO bodies in a single INFO method. | o Described multiple INFO bodies in a single INFO method. | |||
o Took out Info-Package as a header field for responses to the INFO | o Took out Info-Package as a header field for responses to the INFO | |||
method. | method. | |||
o Expanded on risks of using INFO and filled-in more on the | o Expanded on risks of using INFO and filled-in more on the | |||
alternatives | alternatives | |||
o Moved definitions of INFO into the body of the text and cleaned up | o Moved definitions of INFO into the body of the text and cleaned up | |||
IANA Considerations section | IANA Considerations section | |||
o Added legacy usages descriptions | o Added legacy usages descriptions | |||
Authors' Addresses | Authors' Addresses | |||
Christer Holmberg | ||||
Ericsson | ||||
Hirsalantie 11 | ||||
Jorvas, 02420 | ||||
Finland | ||||
Phone: | ||||
Fax: | ||||
Email: christer.holmberg@ericsson.com | ||||
URI: | ||||
Eric W. Burger | Eric W. Burger | |||
NeuStar, Inc. | NeuStar, Inc. | |||
46000 Center Oak Plaza | 46000 Center Oak Plaza | |||
Sterling, VA 20166-6579 | Sterling, VA 20166-6579 | |||
USA | USA | |||
Email: eburger@standardstrack.com | Email: eburger@standardstrack.com | |||
URI: http://www.standardstrack.com | URI: http://www.standardstrack.com | |||
Hadriel Kaplan | Hadriel Kaplan | |||
Acme Packet | Acme Packet | |||
71 Third Ave. | 71 Third Ave. | |||
Burlington, MA 01803 | Burlington, MA 01803 | |||
USA | USA | |||
Phone: | Phone: | |||
Fax: | Fax: | |||
Email: hkaplan@acmepacket.com | Email: hkaplan@acmepacket.com | |||
URI: | URI: | |||
Christer Holmberg | ||||
Ericsson | ||||
Hirsalantie 11 | ||||
Jorvas, 02420 | ||||
Finland | ||||
Phone: | ||||
Fax: | ||||
Email: christer.holmberg@ericsson.com | ||||
URI: | ||||
End of changes. 41 change blocks. | ||||
99 lines changed or deleted | 127 lines changed or added | |||
This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |