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

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/