draft-ietf-sipcore-info-events-04.txt   draft-ietf-sipcore-info-events-05.txt 
SIPCORE C. Holmberg SIPCORE C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: RFC 2976 E. Burger Obsoletes: RFC 2976 E. Burger
(if approved) NeuStar, Inc. (if approved) NeuStar, Inc.
Intended status: Standards Track H. Kaplan Intended status: Standards Track H. Kaplan
Expires: July 18, 2010 Acme Packet Expires: July 22, 2010 Acme Packet
January 14, 2010 January 18, 2010
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-04 draft-ietf-sipcore-info-events-05
Abstract Abstract
This document defines a new method, INFO, for the Session Initiation This document defines a method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261], and an Info Package mechanism. The Protocol (SIP) [RFC3261], and an Info Package mechanism. The
document obsoletes [RFC2976]. For backward compatibility the document obsoletes [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.
Conventions Used in this Document Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
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 July 18, 2010. This Internet-Draft will expire on July 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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
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 . . . . . . . . . . . . . . . . 15 6.2. Info-Package header field . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 21 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . 22 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . 23 10.10. Info Package Security Considerations . . . . . . . . . . 22
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 . . 24
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 . . . . . . . . . . . . . . . . . . . . 28 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . 32 14.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 35 Appendix A. Legacy INFO Usage . . . . . . . . . . . . . . . . . . 34
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 35 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document defines a new method, INFO, for the Session Initiation This document defines a method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261]. Protocol (SIP) [RFC3261].
The purpose of the INFO message is to carry application level The purpose of the INFO message is to carry application level
information between endpoints, using the SIP dialog signaling path. information between endpoints, using the SIP dialog signaling path.
Note that the INFO method is not used to update characteristics of a Note that the INFO method is not used to update characteristics of a
SIP dialog or session, but to allow the applications which use the SIP dialog or session, but to allow the applications which use the
SIP session to exchange information (which might 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. Use of the INFO method does not constitute a separate dialog usage.
skipping to change at page 5, line 48 skipping to change at page 5, line 48
requests for any Info-Package, but to inform other UAs that it still requests for any Info-Package, but to inform other UAs that it still
supports the Info Package mechanism. supports the Info Package mechanism.
When a UA sends an INFO request, it uses the Info-Package header When a UA sends an INFO request, it uses the Info-Package header
field to indicate which Info Package is associated with the request. field to indicate which Info Package is associated with the request.
One particular INFO request can only be associated with a single Info One particular INFO request can only be associated with a single Info
Package. Package.
2. Applicability 2. Applicability
This document defines a new method, INFO, for the Session Initiation This document defines a method, INFO, for the Session Initiation
Protocol (SIP) [RFC3261], and an Info Package mechanism. The Protocol (SIP) [RFC3261], and an Info Package mechanism. The
document obsoletes [RFC2976]. For backward compatibility the document obsoletes [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
3.1. General 3.1. General
skipping to change at page 7, line 25 skipping to change at page 7, line 25
the UAC before the dialog creating response, and might therefore be the UAC before the dialog creating response, and might therefore be
rejected by the UAC. In addition, an INFO request might be rejected rejected by the UAC. In addition, an INFO request might be rejected
due to a race condition, if a UA sends the INFO request at the same due to a race condition, if a UA sends the INFO request at the same
time as the remote UA sends a new set of Info Packages for which it time as the remote UA sends a new set of Info Packages for which it
is willing to receive INFO requests. is willing to receive INFO requests.
3.2.2. INFO Request Receiver 3.2.2. INFO Request Receiver
If a UA receives an INFO request associated with an Info Package that If a UA receives an INFO request associated with an Info Package that
the UA has not indicated willingness to receive, the UA MUST send a the UA has not indicated willingness to receive, the UA MUST send a
469 (Bad INFO Package) response (see Section 11.6). In the 469 (Bad INFO Package) response (see Section 11.6), which contains a
terminology of Multiple Dialog Usages [RFC5057], this represents a Recv-Info Header field with Info Packages for which the UA is willing
Transaction Only failure, and does not terminate the invite dialog to receive INFO requests. The UA MUST NOT use the response to update
the set of Info Packages, but simply to indicate the current set. In
the terminology of Multiple Dialog Usages [RFC5057], this represents
a Transaction Only failure, and does not terminate the invite dialog
usage. usage.
If a UA receives an INFO request associated with an Info Package and If a UA receives an INFO request associated with an Info Package and
the message body part with Content-Disposition 'Info-Package' (see the message body part with Content-Disposition 'Info-Package' (see
Section 3.3.1) has a MIME type that the UA supports but not in the Section 3.3.1) has a MIME type that the UA supports but not in the
context of that Info Package, it is RECOMMENDED that the UA send a context of that Info Package, it is RECOMMENDED that the UA send 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
skipping to change at page 8, line 35 skipping to change at page 8, line 35
single MIME type, or it can be a multipart [RFC5621] which contains single MIME type, or it can be a multipart [RFC5621] which contains
other body parts associated with the Info Package. other body parts associated with the Info Package.
UAs MUST support multipart body parts in accordance with [RFC5621]. UAs MUST support multipart body parts in accordance with [RFC5621].
NOTE: An INFO request can also contain other body parts that are NOTE: An INFO request can also contain other body parts that are
meaningful within the context of an invite dialog usage but are not meaningful within the context of an invite dialog usage but are not
specifically associated with the INFO method and the application specifically associated with the INFO method and the application
concerned. concerned.
When a UA supports a specific Info-Package, the UA also support all When a UA supports a specific Info-Package, the UA MUST also support
message body MIME types associated with that Info-Package. However, message body MIME types in accordance with that Info-Package.
in accordance with [RFC3261] the UA still indicates the supported However, in accordance with [RFC3261] the UA still indicates the
MIME types using the Accept header. supported 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
MUST only be sent in INFO requests. MUST only be sent in INFO requests.
A UA MAY include a message body which is not associated with an Info A UA MAY include a message body which is not associated with an Info
Package in an INFO response. Package in an INFO response.
3.4. Order of Delivery 3.4. Order of Delivery
The Info Package mechanism does not define a delivery order The Info Package mechanism does not define a delivery order
mechanism. Info Packages can rely on the CSeq header field to detect mechanism. Info Packages can rely on the CSeq header field to detect
if an INFO request is received out of order. if an INFO request is received out of order.
If specific applications need additional mechanisms for order of If specific applications need additional mechanisms for order of
delivery, those mechanisms, and related procedures, are specified as delivery, those mechanisms, and related procedures, are specified as
part of the associated Info Package, and possible sequence numbers part of the associated Info Package (e.g. the use of sequence numbers
etc must be defined as application data. within the application data).
4. Info Packages 4. Info Packages
4.1. General 4.1. General
An Info Package specification defines the content and semantics of An Info Package specification defines the content and semantics of
the information carried in an INFO message associated with an Info the information carried in an INFO message associated with an Info
Package. The Info Package mechanism provides a way for UAs to Package. The Info Package mechanism provides a way for UAs to
indicate for which Info Packages they are willing to receive INFO indicate for which Info Packages they are willing to receive INFO
requests, and which Info Package a specific INFO request is requests, and which Info Package a specific INFO request is
skipping to change at page 9, line 33 skipping to change at page 9, line 33
4.2.1. General 4.2.1. General
This section describes how a UA handles Info Packages, how a UA uses This section describes how a UA handles Info Packages, how a UA uses
the Recv-Info header field, and how the UA acts in re-INVITE rollback the Recv-Info header field, and how the UA acts in re-INVITE rollback
situations. situations.
4.2.2. UA Procedures 4.2.2. UA Procedures
A UA which supports the Info Package mechanism MUST indicate, using A UA which supports the Info Package mechanism MUST indicate, using
the Revc-Info header field, the set of Info Packages for which it is the Recv-Info header field, the set of Info Packages for which it is
willing to receive INFO requests. A UA can list multiple Info willing to receive INFO requests. 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 use an empty Recv-Info multiple Recv-Info header fields. A UA can use an empty Recv-Info
header 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
skipping to change at page 10, line 8 skipping to change at page 10, line 8
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.
Example: If a UA has previously indicated Info Packages 'foo' and Example: If a UA has previously indicated Info Packages 'foo' and
'bar' in a Recv-Info header field, and the UA during the lifetime of 'bar' in a Recv-Info header field, and the UA during the lifetime of
the invite dialog usage wants to indicate that it does not want to the invite dialog usage wants to indicate that it does not want to
receive INFO requests for any Info Packages anymore, the UA sends a receive INFO requests for any Info Packages anymore, the UA sends a
message with an empty Recv-Info header field. message with an empty Recv-Info header field.
Once a UA has sent a set of Info Packages, the set is valid until the Once a UA has sent a message with a Recv-Info header field containing
UA sends a new set, or an empty Recv-Info header field. a set of Info Packages, the set is valid until the UA sends a new
Recv-Info header field containing a new, or empty, set of Info
Packages.
Once a UA has indicated that it is willing to receive INFO requests Once a UA has indicated that it is willing to receive INFO requests
for a specific Info Package, and a dialog has been established, the for a specific Info Package, and a dialog has been established, the
UA MUST be prepared to receive INFO request associated with that Info UA MUST be prepared to receive INFO request associated with that Info
Package until the UA indicates that it is no longer willing to Package until the UA indicates that it is no longer willing to
receive INFO requests associated with that Info Package. receive INFO requests associated with that Info Package.
For a specific dialog usage, a UA MUST NOT send an INFO request For a specific dialog usage, a UA MUST NOT send an INFO request
associated with an Info Package until it has received an indication associated with an Info Package until it has received an indication
that the remote UA is willing to receive INFO requests for that Info that the remote UA is willing to receive INFO requests for that Info
skipping to change at page 11, line 26 skipping to change at page 11, line 28
- The receiver of a request which contains a Recv-Info header field - The receiver of a request which contains a Recv-Info header field
MUST include a Recv-Info header field in a reliable 18x/2xx response MUST include a Recv-Info header field in a reliable 18x/2xx response
to the request, even if the request contains an empty Recv-Info to the request, even if the request contains an empty Recv-Info
header field, and even if the header field value of the receiver has 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. 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 - 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. associated request did not contain a Recv-Info header field.
NOTE: Different from the rules for generating SDP answers, the NOTE: Different from the rules for generating SDP answers [RFC3264],
receiver of a request which contains a set of Info Packages is not the receiver of a request which contains a set of Info Packages is
restricted to generate its own set of Info Packages as a subset of not restricted to generate its own set of Info Packages as a subset
the Info Package set received in the Info Package header field of the of the Info Package set received in the Info Package header field of
request. the request.
NOTE: Similar to SDP answers, the receiver can include the same Recv- Similar to SDP answers, the receiver can include the same Recv-Info
Info header field value in multiple responses (18x/2xx) for the same header field value in multiple responses (18x/2xx) for the same
INVITE/re-INVITE transaction, but the receiver is not allowed to INVITE/re-INVITE transaction, but the receiver MUST NOT include a
include a Recv-Info header field value which is different from a Recv-Info header field value which is different from a value that the
value that the receiver has already included in a response for the receiver has already included in a response for the same transaction.
same transaction.
4.2.4. Info Package fallback rules 4.2.4. Info Package fallback rules
If the receiver of a request which contains a Recv-Info header field If the receiver of a request which contains a Recv-Info header field
rejects the request, both the sender and receiver of the request MUST rejects the request, both the sender and receiver of the request MUST
roll back to the set of Info Packages which was used before the roll back to the set of Info Packages which was used before the
request was sent. This also applies to the case where the receiver request was sent. This also applies to the case where the receiver
of an INVITE/re-INVITE request has included a Recv-Info header field of an INVITE/re-INVITE request has included a Recv-Info header field
in a provisional response, but later rejects the request. in a provisional response, but later rejects the request.
skipping to change at page 12, line 20 skipping to change at page 12, line 20
specification describes how the header field value shall be specification describes how the header field value shall be
interpreted and used by the registrar, e.g. in order to determine interpreted and used by the registrar, e.g. in order to determine
request targets. request targets.
Rather than using the Recv-Info header field in order to determine Rather than using the Recv-Info header field in order to determine
request targets, it is recommended to use more appropriate request targets, it is recommended to use more appropriate
mechanisms, e.g. based on [RFC3840]. However, this document does not mechanisms, e.g. based on [RFC3840]. However, this document does not
define a feature tag for the Info Package mechanism, or a mechanism define a feature tag for the Info Package mechanism, or a mechanism
to define feature tags for specific Info Packages. to define feature tags for specific Info Packages.
4.4. OPTIONS Processing
If a UA sends an OPTIONS request, or a response, the UA SHALL include
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
skipping to change at page 14, line 25 skipping to change at page 14, line 15
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 proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD
------------------------------------------------------------------ ------------------------------------------------------------------
Info-Package R - - - - - - - m* - - Info-Package R - - - - - - - m* - -
Info-Package 469 - - - - - - - m* - - Recv-Info R - - - m - o o - - o
Recv-Info R - - - m m o o - - o Recv-Info 2xx - - - o** - - o***- - o***
Recv-Info 2xx - - - o** m - o***- - o***
Recv-Info 1xx - - - o** - - - - - - Recv-Info 1xx - - - o** - - - - - -
Recv-Info r - - - o o - o - - o Recv-Info 469 - - - - - - - m* - -
Recv-Info r - - - o - - o - - o
Header field where SUB NOT RFR Header field where SUB NOT RFR
-------------------------------- --------------------------------
Info-Package R - - - Info-Package R - - -
Info-Package 469 - - -
Recv-Info R - - - Recv-Info R - - -
Recv-Info 2xx - - - Recv-Info 2xx - - -
Recv-Info 1xx - - - Recv-Info 1xx - - -
Recv-Info 469 - - -
Recv-Info r - - - Recv-Info r - - -
Table 2: INFO-related Header Fields
The support and usage of the Info-Package and Recv-Info header fields The support and usage of the Info-Package and Recv-Info header fields
is not applicalbe to UAs that only support legacy INFO usages. * Not is not applicalbe to UAs that only support legacy INFO usages.
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 * Not 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.
6.2. Info-Package header field 6.2. Info-Package header field
This document adds Info-Package to the definition of the element This document adds Info-Package to the definition of the element
"message-header" in the SIP message grammar [RFC3261]. Section 3 "message-header" in the SIP message grammar [RFC3261]. Section 3
describes the Info-Package header field usage. describes the Info-Package header field usage.
For the purposes of matching Info Package types indicated in Recv- For the purposes of matching Info Package types indicated in Recv-
Info with those in the Info-Package header field value, one compares Info with those in the Info-Package header field value, one compares
the Info-package-name portion of the Info-package-type portion of the the Info-package-name portion of the Info-package-type portion of the
skipping to change at page 17, line 16 skipping to change at page 17, line 10
As for any other SIP signaling plane based mechanism for transporting As for any other SIP signaling plane based mechanism for transporting
application information, the SUBSCRIBE/NOTIFY messages can put a application information, the SUBSCRIBE/NOTIFY messages can put a
significant burden on intermediate SIP entities which are part of the significant burden on intermediate SIP entities which are part of the
dialog route set, but do not have any interest in the application dialog route set, but do not have any interest in the application
information transported between the end users. information transported between the end users.
7.4.1.3. MESSAGE 7.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. user.
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 intermediaries to examine the information, it for the SIP signaling intermediaries to examine the information, it
skipping to change at page 18, line 12 skipping to change at page 18, line 9
HTTP [RFC2616]. In this model, the UA knows about a rendezvous point HTTP [RFC2616]. In this model, the UA knows about a rendezvous point
to direct HTTP requests to for the transfer of information. Examples to direct HTTP requests to for the transfer of information. Examples
include encoding of a prompt to retrieve in the SIP Request URI in include encoding of a prompt to retrieve in the SIP Request URI in
[RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC- [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-
voicexml21-20070619] script. voicexml21-20070619] script.
8. Syntax 8. Syntax
8.1. General 8.1. General
This section describes the syntax extensions required for the INFO This section describes the syntax extensions to the ABNF syntax
method, and for the Info-Package and Recv-Info header fields. The defined in [RFC3261] required for the INFO method, and adds
previous sections describe the semantics. Note the formal syntax definitions for the Info-Package and Recv-Info header fields. The
definitions described in this document use the ABNF format used in previous sections describe the semantics. The ABNF defined in this
[RFC3261] and contain references to elements defined therein. specification is conformant to [RFC5234].
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 Method =/ INFOm
message-header =/ (Info-Package / Recv-Info) CRLF
Info-Package = "Info-Package" HCOLON Info-package-type Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON [Info-package-list] Recv-Info = "Recv-Info" HCOLON [Info-package-list]
Info-package-list = Info-package-type *( COMMA Info-package-type ) Info-package-list = Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( SEMI Info-package-param) Info-package-type = Info-package-name *( SEMI Info-package-param)
Info-package-name = token Info-package-name = token
Info-package-param = generic-param Info-package-param = generic-param
9. Legacy INFO Usage 9. Legacy INFO Usage
9.1. General 9.1. General
skipping to change at page 21, line 13 skipping to change at page 21, line 4
mechanisms which one should consider for solving a specific use-case. mechanisms which one should consider for solving a specific use-case.
10.4. Info Package Name 10.4. Info Package Name
The Info Package specification MUST define an Info Package name, The Info Package specification MUST define an Info Package name,
which UAs use as a header field value (e.g. "infoX") to identify the which UAs use as a header field value (e.g. "infoX") to identify the
Info Package in the Recv-Info and Info-Package header fields. The Info Package in the Recv-Info and Info-Package header fields. The
header field value MUST conform to the ABNF defined in Section 8.2. header field value MUST conform to the ABNF defined in Section 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.
The IANA registration requirements for Info Package names are defined
in Section 10.5.
10.5. Info Package Parameters 10.5. Info Package Parameters
The Info Package specification MAY define Info Package parameters, The Info Package specification MAY define Info Package parameters,
which can be used in the Recv-Info or Info-Package header fields, which can be used in the Recv-Info or Info-Package header fields,
together with the header field value which indicates the Info Package together with the header field value which indicates the Info Package
name (see Section 10.4. name (see Section 10.4.
The Info Package specification MUST define the syntax and semantics The Info Package specification MUST define the syntax and semantics
of the defined parameters. In addition, the specification MUST of the defined parameters. In addition, the specification MUST
define whether a specific parameter is only applicable to the Recv- define whether a specific parameter is only applicable to the Recv-
skipping to change at page 24, line 37 skipping to change at page 24, line 28
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. Packages.
Based on [RFC5226], IANA assigns an expert in order to review an Info The registration policy for the registry is Specification Required
Package which is to be registered. The Info Package specification is [RFC5226].
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 The reviewer does not consider the applicability of the Info Package
for the usage for which it is defined. 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 insensitive 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 Reference: A reference to a specification which describes the Info o Reference: A reference to a specification which describes the Info
Package. Package.
skipping to change at page 32, line 30 skipping to change at page 31, line 30
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC5621] Camarillo, G., "Message Body Handling in the Session [RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, September 2009. Initiation Protocol (SIP)", RFC 5621, September 2009.
14.2. Informative References 14.2. Informative References
skipping to change at page 33, line 12 skipping to change at page 32, line 15
[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.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001. RFC 3080, March 2001.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004. BCP 85, RFC 3725, April 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
skipping to change at page 34, line 33 skipping to change at page 33, line 40
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., McGlashan, S., Oshry, M., Auburn, R., Oshry, M., Rehor, K., Bodell, M., Burke, D., Auburn, R.,
Rehor, K., Bodell, M., Burke, D., Baggia, P., Candell, E., Baggia, P., McGlashan, S., Candell, E., Burnett, D.,
Burnett, D., and J. Carter, "Voice Extensible Markup Carter, J., Lee, A., and B. Porter, "Voice Extensible
Language (VoiceXML) 2.1", World Wide Web Consortium Markup Language (VoiceXML) 2.1", World Wide Web Consortium
Recommendation REC-voicexml21-20070619, June 2007, Recommendation REC-voicexml21-20070619, June 2007,
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>. <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[I-D.ietf-speechsc-mrcpv2] [I-D.ietf-speechsc-mrcpv2]
Shanmugham, S. and D. Burnett, "Media Resource Control Shanmugham, S. and D. Burnett, "Media Resource Control
Protocol Version 2 (MRCPv2)", Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-20 (work in progress), draft-ietf-speechsc-mrcpv2-20 (work in progress),
August 2009. August 2009.
[I-D.saleem-msml] [I-D.saleem-msml]
skipping to change at page 36, line 36 skipping to change at page 35, line 43
to prepare this document for publication. to prepare this document for publication.
Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided
valuable input in order to sort out the message body part usage for valuable input in order to sort out the message body part usage for
Info Packages. Info Packages.
Appendix C. Change Log Appendix C. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-sipcore-info-events-04
o Further changes based on WGLC comments
o OPTIONS processing removed
o Clarification of Recv-Info header field in INFO 469 response added
o IANA registry procedures clarified
Changes from draft-ietf-sipcore-info-events-03 Changes from draft-ietf-sipcore-info-events-03
o Further changes based on WGLC comments o Further changes based on WGLC comments
o New section 3.2.3 added 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
skipping to change at page 38, line 4 skipping to change at page 37, line 17
advertisement advertisement
o Split Section 3 into UAS and UAC behavior o Split Section 3 into UAS and UAC behavior
o Moved the example in section 3 into its own sub-section, and used o Moved the example in section 3 into its own sub-section, and used
full SIP header fields full SIP header fields
o Clarified forking behavior o Clarified forking behavior
o Clarified language around when to send a body o Clarified language around when to send a body
o Added 469 error response, instead of reusing 489 o Added 469 error response, instead of reusing 489
o Clarified overlapping INFO method handling o Clarified overlapping INFO method handling
o Fixed table 1 to follow 3261, not 2543 o Fixed table 1 to follow 3261, not 2543
o Added REFER to the INFO Headers table o Added REFER to the INFO Headers table
o replaced token-nodot with token for Info-Package header field o Replaced token-nodot with token for Info-Package header field
values values
o Clarified end-to-end security considerations o Clarified end-to-end security considerations
o Info Package parameters are semi-colon delimited, not dot o Info Package parameters are semi-colon delimited, not dot
delimited delimited
Changes from -02 Changes from -02
o Applicability statement explicitly says we're backwards compatible o Applicability statement explicitly says we're backwards compatible
o Explicitly state we work like UPDATE (both early and confirmed o Explicitly state we work like UPDATE (both early and confirmed
dialogs) dialogs)
o Agreed text for IANA Considerations package registry o Agreed text for IANA Considerations package registry
 End of changes. 41 change blocks. 
91 lines changed or deleted 99 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/