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

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