draft-ietf-sipcore-info-events-01.txt   draft-ietf-sipcore-info-events-02.txt 
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Obsoletes: RFC 2976 H. Kaplan Obsoletes: RFC 2976 H. Kaplan
(if approved) Acme Packet (if approved) Acme Packet
Expires: April 2, 2010 C. Holmberg Expires: April 26, 2010 C. Holmberg
Ericsson Ericsson
September 29, 2009 October 23, 2009
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-01 draft-ietf-sipcore-info-events-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2, 2010. This Internet-Draft will expire on April 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document provides new semantics for the SIP INFO method of RFC This document defines a new method, INFO, for the Session Initiation
2976. These new semantics defined here are fully backwards Protocol (SIP) [RFC3261], and an Info Package mechanism. The
compatible with the old semantics. Core to the new semantics is a document obsoletes [RFC2976]. For backward compatibility the
mechanism for defining, indicating support of, and exchanging Info document also specifies a "legacy" mode of usage of the INFO method
Packages that use the INFO method. Applications that need to that is compatible with the usage previously defined in [RFC2976],
exchange application information within a SIP invite usage dialog referred to as "legacy INFO Usage" in this document.
(RFC 5057), can use these Info Packages. This document replaces RFC
2976 but still allows existing legacy INFO usages as defined in RFC
2976.
Conventions Used in this Document Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terminology in this document conforms to the Internet Security The terminology in this document conforms to the Internet Security
Glossary [RFC4949]. Glossary [RFC4949].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Info Package Support . . . . . . . . . . . . . . . . . . . . . 7 3. Info Package Support . . . . . . . . . . . . . . . . . . . . . 6
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7 3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 6
3.3. Package Versioning . . . . . . . . . . . . . . . . . . . . 8 3.3. Package Versioning . . . . . . . . . . . . . . . . . . . 7
3.4. REGISTER Processing . . . . . . . . . . . . . . . . . . . 8 3.4. REGISTER Processing . . . . . . . . . . . . . . . . . . . 7
3.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 8 3.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . 8
3.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 8
4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . 8
4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. INFO Request Message Body . . . . . . . . . . . . . . . . 9
4.3. INFO Request Message Body . . . . . . . . . . . . . . . . 11 4.4. INFO Response . . . . . . . . . . . . . . . . . . . . . . 10
4.4. INFO Response . . . . . . . . . . . . . . . . . . . . . . 12 4.5. INFO Response Message Body . . . . . . . . . . . . . . . 11
4.5. INFO Response Message Body . . . . . . . . . . . . . . . . 12 4.6. Order of Delivery . . . . . . . . . . . . . . . . . . . . 11
4.6. Order of Delivery . . . . . . . . . . . . . . . . . . . . 12 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 11
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13 6. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . . 13
5.2. INFO Header Fields . . . . . . . . . . . . . . . . . . . . 14 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Info-Package header field . . . . . . . . . . . . . . 15 6.2. Info-Package header field . . . . . . . . . . . . . . . . 13
5.2.2. Recv-Info header field . . . . . . . . . . . . . . . . 15 6.3. Recv-Info header field . . . . . . . . . . . . . . . . . 14
6. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 15 7. Info Package Considerations . . . . . . . . . . . . . . . . . 14
7. Info Package Requirements . . . . . . . . . . . . . . . . . . 16 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Appropriateness of Info Package Usage . . . . . . . . . . 14
7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 14
7.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 17 7.4. INFO Request Rate and Volume . . . . . . . . . . . . . . 14
7.4. Info Package Parameters . . . . . . . . . . . . . . . . . 17 7.5. Alternative Mechanisms . . . . . . . . . . . . . . . . . 15
7.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 17 7.5.1. Alternative SIP signaling plane mechanisms . . . . . . 15
7.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 17 7.5.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 16
7.7. Info Package Usage Restrictions . . . . . . . . . . . . . 17 7.5.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 17
7.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 18 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.9. IANA Registrations . . . . . . . . . . . . . . . . . . . . 18 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.10. Security Considerations . . . . . . . . . . . . . . . . . 18 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.11. Application Procedures . . . . . . . . . . . . . . . . . . 19 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 17
7.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. Co-existence with Info Package based INFO usage . . . . . 18
8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Update to Registration of SIP INFO Method . . . . . . . . 20 10.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Registration of the Info-Package Header Field . . . . . . 20 10.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 19
9.3. Registration of the Recv-Info Header Field . . . . . . . . 20 10.4. Info Package Parameters . . . . . . . . . . . . . . . . . 20
9.4. Creation of the Info Packages Registry . . . . . . . . . . 20 10.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 20
9.5. Registration of the Info-Package Content-Disposition . . . 21 10.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 20
9.6. SIP Response Code 469 Registration . . . . . . . . . . . . 21 10.7. Info Package Usage Restrictions . . . . . . . . . . . . . 20
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 21
10.1. Simple Info Package . . . . . . . . . . . . . . . . . . . 21 10.9. IANA Registrations . . . . . . . . . . . . . . . . . . . 21
10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 22 10.10. Info Package Security Considerations . . . . . . . . . . 21
11. Modifications to SIP Change Process . . . . . . . . . . . . . 23 10.11. Application Procedures . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 25 11.1. Update to Registration of SIP INFO Method . . . . . . . . 22
Appendix A. Info Package Considerations . . . . . . . . . . . . . 27 11.2. Registration of the Info-Package Header Field . . . . . . 22
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.3. Registration of the Recv-Info Header Field . . . . . . . 23
A.2. Appropriateness of Info Package Usage . . . . . . . . . . 27 11.4. Creation of the Info Packages Registry . . . . . . . . . 23
A.3. Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 27 11.5. Registration of the Info-Package Content-Disposition . . 24
A.4. INFO Request Rate and Volume . . . . . . . . . . . . . . . 27 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 24
A.5. Alternative Mechanisms . . . . . . . . . . . . . . . . . . 28 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.5.1. Alternative SIP signaling plane mechanisms . . . . . . 28 12.1. Indication of which Info Packages UAs are willing to
A.5.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 29 receive INFO requests within an invite dialog usage . . . 24
A.5.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 29 12.2. INFO request with information associated with a
Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 29 simple Info Package . . . . . . . . . . . . . . . . . . . 25
B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.3. Multipart INFO Example . . . . . . . . . . . . . . . . . 25
B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
B.5. Video Fast Update . . . . . . . . . . . . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Appendix A. Legacy INFO Usages . . . . . . . . . . . . . . . . . 30
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 31 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 31
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
[RFC3261] defines a mechanism to setup and tear down SIP sessions. A This document defines a new method, INFO, for the Session Initiation
SIP User Agent (UA) can use the re-INVITE and UPDATE methods during a Protocol (SIP) [RFC3261].
session to change characteristics of the session, including media
properties, target information or properties related to the SIP
session timer mechanism [RFC4028].
The purpose of the INFO message [RFC2976] is to carry application
level information between endpoints, using the SIP session signaling
path. Note that the INFO method is not used to update
characteristics of the SIP session, but to allow the applications
which use the SIP session to exchange information.
While the INFO method has been widely adopted for specific
application use cases, such as ISUP and DTMF exchange, [RFC2976] does
not define a mechanisms for SIP UAs to indicate what usages of INFO
they support. In addition, [RFC2976] does not provide a mechanism to
explicitly indicate the type of application for which the INFO
message is used. In some cases it can be determined by the INFO
message body content, but not in a general way.
Example: If the Content-Type is "image/jpeg", the MIME-attached
content is a JPEG image. Still, there are many useful ways a UA can
render an image. The image could be a caller-id picture, a contact
icon, a photo for sharing, and so on. The sender does not know which
image to send to the receiver if the receiver supports an image
content type. Likewise, the receiver does not know the context of an
image the client is sending if the receiver supports receiving more
than one image content type.
Due to the problems described above, the usage of INFO often requires
static configuration about what INFO usages the UAs support, and the
way the handle application information transported in INFO messages.
That has caused a big risk interoperability problems in the industry,
due to undefined content syntax, semantics and UA support of the INFO
messages. Therefore, there is a need for a well defined and
documented description of what the information sent in the INFO is
used for. This situation is identical to the context issue in
Internet Mail [RFC3458].
This document defines a mechanism, using Info Packages, which
provides the possibility for UAs to indicate what INFO usages they
support, and to define content syntax and semantics for the data
transported in the INFO messages. The mechanism allows existing
legacy INFO usages as defined in RFC 2976. New INFO usages MUST use
the mechanism defined in this document.
Event Packages [RFC3265] perform the role of disambiguating the The purpose of the INFO message is to carry application level
context of a message for subscription-based events. The Info Package information between endpoints, using the SIP dialog signaling path.
mechanisms provides similar functionality for application information Note that the INFO method is not used to update characteristics of a
exchange using invite dialog usages [RFC5057]. SIP dialog or session, but to allow the applications which use the
SIP session to exchange information (which may update the state of
those applications).
Note that while Info Packages may be similar to subscription-based This document also defines an Info Package mechanism. An Info
events, there is no formal relationship between this mechanism and Package specification defines the content and semantics of the
the subscription mechanism. information carried in an INFO message associated with the Info
Package. The Info Package mechanism also provides a way for UAs to
for which Info Packages they are willing to receive INFO requests.
The document defines how the INFO method is used, new SIP header
fields for the INFO method, and how to transport payload information
associated with an Info Package using INFO requests.
The Info Package mechanism does not create 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. INFO message can not be sent as part of other dialog dialog usage [RFC5057]. INFO messages cannot be sent as part of
usages, and they can not be sent outside an existing session. other dialog usages.
If a UA supports the Info Package mechanism it indicates, using the A UA uses the Recv-Info header field, on a per-dialog basis, to
Recv-Info header field which Info Packages it is willing to receive, indicate for which Info Packages it is willing to receive INFO
on a per-session basis. A UA can indicate a new set of Info Packages requests. A UA can indicate an initial set of Info Packages during
at any time during the lifetime of the invite dialog usage of the dialog establishment and can indicate a new set during the lifetime
session. A UA can use a "nil" value to indicate that it is not of the invite dialog usage.
willing to receive any Info Packages at a certain moment, but that
the UA still supports the Info Package mechanism. NOTE: A UA can use the Recv-Info header field with a 'nil' value to
indicate that it is not willing to receive INFO requests for any
Info-Package, but to inform other UAs that it still 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
Package.
Section 3 describes the mechanism to indicate support of Info This document obsoletes [RFC2976]. However, for backward
Packages. compatibility it specifies a "legacy" mode of usage of the INFO
method that is compatible with the usage previously defined in
Section 4 describes the usage of INFO messages. [RFC2976], referred to as "legacy INFO Usage" in this document.
Section 6 describes legacy usage of INFO, as defined in [RFC2976].
Section 7 describes guidelines on how to define Info Packages. This
document does not define any specific Info Packages.
Annex A provides guidelines and issues to consider when deciding if
usage of Info Packages is the most appropriate mechanism for a
specific use-case.
2. Applicability 2. Applicability
This document extends [RFC2976] to include a mechanism to in SIP This document defines a new method, INFO, for the Session Initiation
messages explicitly indicate the supported Info Packages, and to Protocol (SIP) [RFC3261], and an Info Package mechanism. The
explicitly indicate what Info Package is associated with an INFO document obsoletes [RFC2976]. For backward compatibility the
request. The mechanism is backward compatible with legacy usage of document also specifies a "legacy" mode of usage of the INFO method
INFO, as defined in [RFC2976], and allows such usage. New INFO that is compatible with the usage previously defined in [RFC2976],
usages MUST use the mechanism defined in this document. referred to as "legacy INFO Usage" in this document.
3. Info Package Support 3. Info Package Support
3.1. General 3.1. General
This section describes how SIP UAs indicate which Info Packages they This section describes how SIP UAs indicate for which Info Packages
are willing to receive. they are willing to receive INFO requests.
3.2. User Agent Behavior 3.2. User Agent Behavior
A UA which supports the Info Package mechanism MUST indicate the set A UA which supports the Info Package mechanism MUST indicate, using
of Info Packages it is willing to receive, using the Revc-Info header the Revc-Info header field, the set of Info Packages for which it is
field. A UA can list multiple Info Packages in a single Recv-Info willing to receive INFO request. A UA can list multiple Info
header field, and the UA can use multiple Recv-Info header fields. Packages in a single Recv-Info header field, and the UA can use
multiple Recv-Info header fields.
The indication of Info Packages can take place during the session The indication of Info Packages can take place during the dialog
establishment, and during a target refresh. This includes INVITE, establishment, and during a target refresh. This includes INVITE,
UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx
only). Note that the UAC is not required to indicate its set of Info only). Note that the UAC is not required to indicate its set of Info
Packages in the initial INVITE request. Packages in the initial INVITE request.
Once a UA has indicated that it is willing to to receive a specific If a UA is not willing to INFO requests for any Info Packages, during
Info Package, and a dialog has been established, the UA MUST be dialog establishment or later during the invite dialog usage, the UA
prepared to receive INFO request associated with that Info Package. MUST indicate this by including a Recv-Info header field with a 'nil'
value. This informs other UAs that the UA still supports the Info
Package mechanism.
A UA MUST NOT send INFO request associated with Info Packages until Example: If a UA has previously indicated Info Packages 'foo' and
it has received an indication of which Info Packages the remote UA is 'bar', and the UA during the lifetime of the invite dialog usage
willing to receive. wants to indicate that it does not want to receive INFO requests for
any Info Packages anymore, the UA sends a target refresh request with
a Recv-Info header field with a header value of 'nil'.
If a UA indicates that it is willing to receive of multiple Info Once a UA has indicated that it is willing to receive INFO requests
Packages, which provide similar functionality, it is not possible to for a specific Info Package, and a dialog has been established, the
indicate that the UA wishes to receive only one of them. It is up to UA MUST be prepared to receive INFO request associated with that Info
the application logic associated with the Info Packages, and specific Package.
Info Package descriptions to describe application behavior in such
cases.
If a UA is not willing to receive any Info Packages, during session A UA MUST NOT send an INFO request associated with an Info Package
establishment or later during the session, the UA MUST indicate this until it has received an indication that the remote UA is willing to
by including a Recv-Info header field with a header value of 'nil'. receive INFO requests for that Info Package, and a dialog has been
This enables other UAs to detect that the UA still supports the Info established with the remote UA.
Package mechanism.
Example: If a UA has previously indicated support of Info Packages If a UA indicates multiple Info Packages, which provide similar
foo and bar, and the UA during the session wants to indicate that it functionality, it is not possible to indicate a priority order of the
does not want to receive any Info Packages anymore, the UA sends a Info Packages, or that that the UA wishes to only receive INFO
target refresh request with a Recv-Info header field with a header request for one of the Info Packages. It is up to the application
value of 'nil'. logic associated with the Info Packages, and specific Info Package
descriptions to describe application behavior in such cases.
For backward compatibility purpose, even if a UA indicates support For backward compatibility purpose, even if a UA indicates support of
the Info Package mechanism, it is still allowed to enable legacy the Info Package mechanism, it is still allowed to enable legacy INFO
usages of INFO. usages Section 9.
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, Info Package specifications MAY define Package mechanism. However, an Info Package specification can define
option-tags associated with the specific Info Package, as described an option-tag associated with the specific Info Package, as described
in Section 7.5. in Section 10.5.
Note that, for backward compatibility purpose, if a UA indicates For backward compatibility, if a UA indicates support of the INFO
support of the INFO method, it does not implicitly indicate support method using the Allow header field [RFC3261], it does not implicitly
of the Info Package mechanism. A UA MUST use the Recv-Info header indicate support of the Info Package mechanism. A UA MUST use the
field to indicate support of the Info Package mechanism. Likewise, Recv-Info header field in order to indicate that it supports the Info
even if a UA uses the Recv-Info header field to indicate that it Package mechanism. Likewise, even if a UA uses the Recv-Info header
support the Info Package mechanism, in addition the UA MUST still field to indicate that it supports the Info Package mechanism, in
also explicitly indicate support of the INFO method. addition the UA MUST still also explicitly indicate support of the
INFO method using the Allow header field.
3.3. Package Versioning 3.3. Package Versioning
The Info Package mechanism does not support package versioning. The Info Package mechanism does not support package versioning.
Specific Info Package payloads MAY contain version information, which Specific Info Package payloads MAY contain version information, which
is handled by the applications associated wit the Info Package, but is handled by the applications associated with the Info Package, but
that is outside the scope of the Info Package framework. that is outside the scope of the Info Package mechanism.
Note: Even if an Info Package name contains version numbering (e.g. NOTE: Even if an Info Package name contains version numbering (e.g.
foo_v2), the Info Package mechanism does not distinguish a version foo_v2), the Info Package mechanism does not distinguish a version
number from the rest of the Info Package name. number from the rest of the Info Package name.
3.4. REGISTER Processing 3.4. REGISTER Processing
When a UA registers, it SHALL include Recv-Info header field in the This document allows a UA to insert a Recv-Info header field in a
REGISTER request, and list the Info Packages that it supports. The REGISTER request. However, a UA SHALL NOT include a header value for
registrar MAY later use the information e.g. for forking decisions. a specific Info Package unless the specific Info Package
specification describes how the header field value shall be
interpreted and used by the registrar, e.g. in order to determine
request targets.
NOTE: Rather than using the Recv-Info header field in order to
determine request targets, it is recommended to use more appropriate
mechanisms, e.g. based on [RFC3840].
3.5. OPTIONS Processing 3.5. OPTIONS Processing
If a UA sends an OPTIONS request, or a response, the UA SHALL include If a UA sends an OPTIONS request, or a response, the UA SHALL include
Recv-Info header field in the message, and list the Info Packages Recv-Info header field in the message, and list the Info Packages
that it supports. that it supports to receive.
A UA MUST NOT send INFO requests with Info Packages based on the
information the UA received in an OPTIONS request. The Info Packages
MUST be negotiated for each session.
3.6. Example
The UAC sends an INVITE request, where the UAC indicates that it is
willing to receive Info Packages P and R.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Recv-Info: P, R
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: ...
...
The UAS sends a 200 OK response back to the UAC, where the UAS
indicates that it is willing to receive Info 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:alice@pc33.example.com>
Recv-Info: R, T
Content-Type: application/sdp
Content-Length: ...
...
Since the UAS does not support Info Package P, the UAC decides to
indicate in the ACK request that it is only willing to receive Info
Package R, which the UAS also indicated support of.
ACK sip:ngw1@a.example.com SIP/2.0 NOTE: As for any other capability and extension, for a specific
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 dialog UAs need to indicate which Info Packages they are willing to
To: Bob <sip:bob@example.com>;tag=a6c85cf receive within that dialog.
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 ACK
Recv-Info: R
Content-Length: 0
4. The INFO Method 4. The INFO Method
4.1. General 4.1. General
This section describes how the UA handling of INFO requests and This section describes the UA handling of INFO requests and
responses, and message bodies carried in INFO messages. It also responses, and message bodies carried in INFO messages.
describes how an UA can indicate support of Info Packages in OPTIONS
requests and during registration.
The INFO method provides additional, application level information The INFO method provides additional, application level information
that can further enhance a SIP application. Annex A gives more that can further enhance a SIP application. Annex A gives more
details on the types of application for which the usage of INFO is details on the types of application for which the usage of INFO is
seen as appropriate. seen as appropriate.
The rules and procedures in this Section apply to implementations and
applications which support this. Existing implementations of, and
applications using, [RFC2976], may not follow the rules in this
Section. Because of backward compatibility purpose such cases MUST
NOT be regarded as error behavior, or wrong protocol usage, but
simply part of legacy INFO usage.
4.2. INFO Request 4.2. INFO Request
A UA MUST include a Info-Package header field, which indicates the When a UA sends an INFO request associated with an Info Package, it
Info Package contained in the request, when it sends an INFO request MUST include an Info-Package header field that indicates which Info
carrying an Info Package. An INFO request can contain only a single Package is associated with the request. A specific INFO request can
Info Package. A UA MUST NOT send INFO requests associated with Info be used only for a single Info Package. For a specific dialog, a UA
Packages for which the remote entity has not indicated willingness MUST NOT send INFO requests associated with Info Packages that the
(using the Recv-Info header filed) to receive for the session. remote UA has not indicated that it is willing to receive.
A UA MAY send an INFO in a legacy usage context. In such case there A UA can send an INFO requests associated with a legacy INFO usage
is no Info Package associated with the usage, and the INFO request Section 9. In such case there is no Info Package associated with the
does not contain an Info-Package header field. In addition, the usage, and the INFO request does not contain an Info-Package header
support of the legacy usage has not been negotiated using the Recv- field. In addition, the UA cannot use the Recv-Info header field to
Info header field. See Appendix B for examples of legacy usages. indicate whether it is willing to receive INFO requests associated
with that legacy INFO usage.
The INFO method MUST NOT be used outside an INVITE dialog usage. The The INFO method MUST NOT be used outside an invite dialog usage. The
INFO method has no lifetime or usage of its own. Supported Info INFO method has no lifetime beyond its transaction or usage of its
Packages are negotiated on a per session basis, and the negotiation own. UAs indicate, per-dialog basis, for which Info Packages they
result MUST NOT be used for other sessions. If a UA receives an INFO are willing to receive INFO requests. The set of Info Packages
request outside an existing dialog, the UA MUST response with a 481 cannot automatically be used within other dialogs.
Call Does Not Exist error response.
Due to the possibility of forking, a UAC which during the early Due to the possibility of forking, a UAC which, during the early
dialog phase indicates support of one or more Info Packages (using dialog phase indicates that it is willing to receive INFO requests
the Recv-Info header field) MUST be prepared to receive INFO requests for one or more Info Packages MUST be prepared to receive INFO
from multiple remote entities. Note that different remote entities requests associated with those Info Packages from multiple remote
can indicate different sets of Info Packages which they are willing UAs. Note that each remote UA can indicate a different set of Info
to receive. Packages for which they are willing to receive INFO request.
The construction of the INFO request is the same as any other request The construction of the INFO request is the same as any other request
within an existing INVITE dialog usage. A UA can send INFO requests within an existing invite dialog usage. A UA can send INFO requests
both on early and confirmed dialogs. both within early and confirmed dialogs.
The INFO request MUST NOT contain a Recv-Info header field. The UA The INFO request MUST NOT contain a Recv-Info header field. The UA
can only indicate the Info Packages that it is willing to receive can only indicate a set of Info Packages for which it is willing to
using the messages listed in Section 3. receive INFO requests by using the SIP methods (and their responses)
listed in Section 3.
4.3. INFO Request Message Body 4.3. 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 data associated with an information between SIP UAs. The application data associated with an
Info Package SHOULD be carried as a payload in the message body of Info Package is carried as payload in the message body of the INFO
the INFO request, unless the information can be retrieved from a SIP request, using one or more body parts.
header field.
Info Package specifications MUST describe the application level Info Package specifications MUST describe the application level
information associated with the Info Package. Message body payloads information associated with the Info Package. Each body part MUST
MUST have a MIME type value defined. have a MIME type value, and the syntax and content of the body part,
defined.
If a UA indicates that it is willing to receive a specific Info Each body part, when associated with an Info Package, MUST have a
Package, it means that the UA also supports any associated message Content-Disposition header field with an 'Info-Package' value
body MIME type associated with the Info Package. However, the UA assigned, in order to be able distinguish body parts associated with
MUST still indicate support of those MIME types also in the Accept the Info Package from other body parts.
header filed, according to the procedures in [RFC3261].
Some SIP extensions, which are orthogonal to INFO, MAY insert body NOTE: Some SIP functions that are orthogonal to INFO may insert body
parts unrelated to the Info Package. UAs MUST conform to [RFC3261] parts unrelated to the Info Package.
as updated by body-handling [I-D.ietf-sip-body-handling] to support
multipart MIME handling.
Each message body (or body part in the case of multipart MIME) MUST Body parts associated with specific MIME types may sometimes have
contain a Content-Disposition header with an 'Info-Package' header specific Content-Disposition header field values defined for them.
value, in order to in an easy way distinguish payloads associated For example, for body parts with a 'text/plain' MIME a Content-
with the Info Package from other payloads. Disposition header field with a 'render' value is often assigned.
However, when a body part in the INFO message is associated with an
Info Package, it MUST always have a Content-Disposition header field
with an 'Info-Package' value assigned. The Info Package
specification defines how applications process the body part
contents.
If the whole message body is associated with the Info Package, the UA If a SIP message body contains multiple body parts, multipart body
MUST insert a Content-Disposition header with an 'Info-Package' parts [RFC5621] are used to separate them. If all body parts within
header value in the SIP part of the message. In that case, if a multipart body part are associated with the Info Package, the
multipart MIME is used, the UA does not need to insert an 'Info- multipart body part SHALL have a Content-Disposition header field
Package' header value for the individual body parts. with an 'Info-Package' value assigned to it. However, each body part
within the multipart body part MUST still have a Content-Disposition
header field with an 'Info-Package' value assigned to them, in order
to avoid that the parser assigns a default Content-Disposition header
value to the body part.
NOTE: According to [RFC5621], body parts within a multipart are not
implicitly assigned the Content-Disposition header field value of the
multipart body part which they belong to.
This document does not define Info Package specific rules on how body
parts associated with Info Packages are to be inserted into multipart
body parts, and what type of multiparts are used. If an Info Package
requires special rules regarding the usage of multipart body parts,
the specification for that Info Package MUST specify such rules.
UAs MUST conform to [RFC5621] to support multipart body parts.
If a UA indicates that it is willing to receive a specific Info
Package, the UA naturally also supports any associated message body
part MIME type associated with the Info Package. However, in
addition the UA MUST still indicate support of those MIME types in
the Accept header field, according to the procedures in [RFC3261].
NOTE: To avoid corner cases with legacy INFO usage, the Info-Package NOTE: To avoid corner cases with legacy INFO usage, the Info-Package
header field is used to indicate the Info Package name, rather than header field is used to indicate the Info Package name, rather than
to use a Content-Disposition header field parameter in order to to use a Content-Disposition header field parameter in order to
indicate the name. indicate the name.
4.4. INFO Response 4.4. INFO Response
If a UA receives an INFO request, associated with an Info-Package If a UA receives an INFO request, associated with an Info-Package
that the UA has indicated willingness to receive, and the INFO that the UA has indicated willingness to receive, and the INFO
request contains data associated with that Info-Package, the UA MUST request contains data associated with that Info-Package, the UA MUST
send a 200 OK response. send a 200 OK response.
If a UA receives an INFO request, associated with an Info Package
that the UA has not indicated willingness to receive, the UA MUST
send a 469 Bad INFO Package response. In the terminology of Multiple
Dialog Usages [RFC5057], this represents a Transaction Only failure.
If a UA receives an INFO request for legacy usage, for which no Info- If a UA receives an INFO request for legacy usage, for which no Info-
Package is associated (the INFO request does not contain an Info- Package is associated (the INFO request does not contain an Info-
Package header filed), the UA must send a 200 OK response. Package header field), the UA MUST send a 200 OK response.
If a UA receives an INFO request, which does not match any existing The UAS MAY send other responses, such as Request Failure (4xx),
INVITE dialog usage, the UA MUST send a 481 Call Leg/Transaction Does Server Failure (5xx) and Global Failure (6xx) as appropriate for the
request.
If a UA receives an INFO request associated with an Info Package that
the UA has not indicated willingness to receive, the UA MUST send a
469 Bad INFO Package response Section 11.6. In the terminology of
Multiple Dialog Usages [RFC5057], this represents a Transaction Only
failure.
If a UA receives an INFO request that does not match any existing
invite dialog usage, the UA MUST send a 481 Call Leg/Transaction Does
Not Exist response. Not Exist response.
If a UA receives an INFO request, which carries a message body that If a UA receives an INFO request that carries a message body that the
the UA does not support, and support of the message body is required UA does not support, and support of the message body is required in
in the Content-Disposition header field, the UA MUST send a 415 the Content-Disposition header field, the UA MUST send a 415
Unsupported Media Type response. If support of the message body is Unsupported Media Type response. If support of the message body is
optional, the UA MUST send a 200 OK response even if the UA does not optional, the UA MUST send a 200 OK response even if the UA does not
support the message body. support the message body.
The UAS MAY send other responses, such as Request Failure (4xx),
Server Failure (5xx) and Global Failure (6xx) as appropriate for the
request.
4.5. INFO Response Message Body 4.5. INFO Response Message Body
The response to the INFO request is normally generated by the SIP The Info Package mechanism allows a SIP stack to generate a response
stack before the Info Package application data has been provided to to an INFO request without application interaction. As a result,
the application associated with the Info Package. Therefore, an Info Info Packages cannot require a message body in INFO responses,
Package MUST NOT define the inclusion of a message body in an INFO require different response codes, or otherwise require the response
response. to the INFO request to contain application information. If the
application needs to send information in the other direction, it can
If the application that received the information needs to send some send a new INFO request which contains the information.
information in the other direction, it MUST trigger a new INFO
request, rather than using the response of the received INFO request.
4.6. Order of Delivery 4.6. Order of Delivery
The Info Package framework relies on the CSeq header field to detect The Info Package mechanism relies on the CSeq header field to detect
if an INFO request is received out of order. if an INFO request is received out of order.
If specific applications need additional mechanisms for order of If specific applications need additional mechanisms for order of
delivery, those mechanisms, and related procedures, MUST be specified delivery, those mechanisms, and related procedures, must be specified
as part of the associated Info Package, and possible sequence numbers as part of the associated Info Package, and possible sequence numbers
etc MUST be defined as application data. etc must be defined as application data.
5. Formal INFO Method Definition 5. Formal INFO Method Definition
5.1. INFO Method 5.1. INFO Method
This document describes one new SIP method: INFO. This document This document describes one new SIP method: INFO. This document
replaces the definition and registrations found in [RFC2976]. replaces the definition and registrations found in [RFC2976].
This table expands on Tables 2 and 3 in [RFC3261]. This table expands on Tables 2 and 3 in [RFC3261].
skipping to change at page 14, line 37 skipping to change at page 13, line 21
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 Figure 1: Table 1: Summary of Header Fields
5.2. INFO Header Fields 6. INFO Header Fields
6.1. General
This table expands on tables 2 and 3 in [RFC3261]. This table expands on tables 2 and 3 in [RFC3261].
Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT RFR
------------------------------------------------------------------------ ------------------------------------------------------------------------
Info-Package R - - - - - - - m* - - - - - Info-Package R - - - - - - - m* - - - - -
Recv-Info R o - - o o o o - - o - o o Recv-Info R o - - o o o o - - o - - -
Recv-Info 2xx o - - o o - o - - o - o - Recv-Info 2xx o - - o o - o - - o - - -
Recv-Info 1xx o - - o o - o - - o - - - Recv-Info 1xx o - - o o - o - - o - - -
Recv-Info r o - - - o - o - - o - - - Recv-Info r o - - - o - o - - o - - -
* The Info-Package header field is MANDATORY for INFO requests * The Info-Package header field is MANDATORY for INFO requests
associated with Info Packages. The Info-Package header field is not associated with Info Packages. The Info-Package header field is not
applicable for legacy usage INFO requests [RFC2976]. applicable for legacy usage INFO requests [RFC2976].
Table 2: INFO-related Header Fields Table 2: INFO-related Header Fields
5.2.1. Info-Package header field 6.2. Info-Package header field
This document adds Info-Package to the definition of the element This document adds Info-Package to the definition of the element
"message-header" in the SIP message grammar. Section 4 describes the "message-header" in the SIP message grammar [RFC3261]. Section 4
Info-Package header field usage. describes the Info-Package header field usage.
For the purposes of matching Info Package types indicated in Recv- For the purposes of matching Info Package types indicated in Recv-
Info with those in the Info-Package header field value, one compares Info with those in the Info-Package header field value, one compares
the Info-package-name portion of the Info-package-type portion of the the Info-package-name portion of the Info-package-type portion of the
Info-Package header field octet-by-octet with that of the Recv-Info Info-Package header field octet-by-octet with that of the Recv-Info
header field value. That is, the Info Package name is case header field value. That is, the Info Package name is case
sensitive. Info-package-param is not part of the comparison-checking sensitive. Info-package-param is not part of the comparison-checking
algorithm. algorithm.
This document does not define values for Info-Package types. This document does not define values for Info-Package types.
Individual Info Package specifications define these values. Such Individual Info Package specifications define these values. Such
specifications MUST register the values with IANA. These values are specifications MUST register the values with IANA. These values are
Specification Required [RFC5226]. Specification Required [RFC5226].
5.2.2. Recv-Info header field 6.3. Recv-Info header field
This document adds Recv-Info to the definition of the element This document adds Recv-Info to the definition of the element
"general-header" in the SIP [RFC3261] message grammar. Section 3 "message-header" in the SIP message grammar [RFC3261]. Section 3
describes the Recv-Info header field usage. describes the Recv-Info header field usage.
6. Legacy INFO Usage 7. Info Package Considerations
7.1. General
This section covers considerations to take into account when deciding
whether the usage of an Info Package is appropriate for transporting
of application information for a specific use-case.
7.2. Appropriateness of Info Package Usage
When designing an Info Package, for application level information
exchange, it is important to consider: is signaling, using INFO
requests, within a SIP dialog, an appropriate mechanism for the use-
case? Is it because it is the most reasonable and appropriate
choice, or merely because "it's easy"? Choosing an inappropriate
mechanism for a specific use-case can cause negative effects in SIP
networks where the mechanism is used.
7.3. Dialog Fate Sharing
As described in [RFC5057], an INFO request is always part of an
INVITE dialog usage.
One needs to consider the fate of the dialog usage of an INFO request
is rejected. In some cases it may be acceptable that the whole
dialog usage is terminated, while in other cases is is desirable to
maintain the dialog usage.
7.4. INFO Request Rate and Volume
There is no default throttling mechanism for INFO requests. Apart
from the SIP session establishment, the number of SIP messages
exchanged during the lifetime a normal SIP session is rather small.
Some applications, like sending of DTMF tones, can generate a burst
of up to 20 messages per second. Other applications, like constant
GPS location updates, could generate a high rate of INFO requests
during the lifetime of the invite dialog usage.
Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
exchange of bulk data beyond these limits, especially if the headers
plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for
such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user
plane data transport mechanisms.
7.5. Alternative Mechanisms
7.5.1. Alternative SIP signaling plane mechanisms
7.5.1.1. General
This subsection describes some alternative mechanisms for
transporting application information on the SIP signaling plane,
using SIP messages.
7.5.1.2. SUBSCRIBE/NOTIFY
An alternative for application level interaction is to use
subscription-based events [RFC3265], which uses the SIP SUBSCRIBE and
NOTIFY methods. Using that mechanism, a user agent requests state
information, such as key pad presses from a device to an application
server or key map images from an application server to a device.
Event Packages [RFC3265] perform the role of disambiguating the
context of a message for subscription-based events. The Info Package
mechanism provides similar functionality for application information
exchange using invite dialog usages [RFC5057].
While an INFO request is always part of, and shares the fate of, an
existing invite dialog usage, a SUBSCRIBE request creates a new
session and a subscription dialog usage [RFC5057] which is separate,
and does not share the fate any other sessions.
The subscription-based mechanism can be used by SIP entities to
receive state information about SIP dialogs and sessions, without
requiring the entities to be part of the route set of those dialogs
and sessions.
As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies
and B2BUAs, the resource impact caused by the subscription sessions
needs to be considered. The number of subscription sessions per user
also needs to be considered.
As for any other SIP signaling plane based mechanism for transporting
application information, the SUBSCRIBE/NOTIFY messages can put a
significant burden on intermediate SIP entities which are part of the
dialog route set, but do not have any interest in the application
information transported between the end users.
7.5.1.3. MESSAGE
The MESSAGE method [RFC3428] defines one-time instant message
exchange, typically for sending MIME contents for rendering to the
ser.
7.5.2. Media Plane Mechanisms
7.5.2.1. General
In SIP, media plane channels associated with SIP dialogs are
established using SIP signaling, but the data exchanged on the media
plane channel does not traverse SIP signaling intermediates, so if
there will be a lot of information exchanged, and there is no need
for the SIP signaling intermediates routing to examine the
information, it is recommended to use a media plane mechanism, rather
than a SIP signaling based.
A low latency requirement for the exchange of information is one
strong indicator for using a media channel. Exchanging information
through the SIP routing network can introduce hundreds of
milliseconds of latency.
7.5.2.2. MRCPv2
One mechanism for media plane exchange of application data is MRCPv2
[I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented
channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is
established.
7.5.2.3. MRSP
MSRP [RFC4975] defines session-based instant messaging as well as
bulk file transfer and other such large-volume uses.
7.5.3. Non-SIP related mechanisms
Another alternative is to use a totally externally signaled channel,
such as HTTP [RFC2616]. In this model, the user agent knows about a
rendezvous point to direct HTTP requests to for the transfer of
information. Examples include encoding of a prompt to retrieve in
the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target
in a VoiceXML [W3C.REC-voicexml21-20070619] script.
8. Syntax
8.1. General
This Section describes the syntax extensions required for the INFO
method. The previous sections describe the semantics. Note the
formal syntax definitions described in this document use the ABNF
format used in [RFC3261] and contain references to elements defined
therein.
8.2. ABNF
INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON Info-package-list
Info-package-list = "nil"
/ Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( ";" Info-package-param)
Info-package-name = token
Info-package-param = generic-param
NOTE on the Recv-Info production: if the header field value is "nil",
the header field MUST NOT contain any other Info Packages, and the
SIP message MUST NOT contain more than one Recv-Info header field.
9. Legacy INFO Usage
9.1. General
A number of applications, standardized and proprietary, make use of A number of applications, standardized and proprietary, make use of
INFO messages as defined in [RFC2976], without defined Info Packages the INFO method as it was previously defined in [RFC2976], referred
the and a possibility to use SIP to indicate what INFO usages UAs are to as "legacy INFO usage".
willing to use. For backward compatibility purpose, this document
does not deprecate such usage, and does not mandate to define Info
Packages for existing usages. However, any new usage of INFO SHALL
use the Info Package mechanism defined in this specification.
Since legacy INFO usages to not have associated Info Packages, it is For backward compatibility purpose, this document does not deprecate
not possible to use the Recv-Info and Info-Package header fields for such usages, and does not mandate users to define Info Packages for
legacy INFO usages. That is, a UA can not use the Recv-Info header such usages. However, any new usage of INFO SHALL use the Info
filed to indicate for which legacy usages it is willing to receive Package mechanism defined in this specification.
INFO requests, and a UA can not use the Info-Package header to
indicate for which legacy INFO usage an INFO request is associated
with.
NOTE: For legacy INFO usages, static configuration is often used to 9.2. Problems
define what specific legacy INFO usages UAs support.
An INFO request associated with an Info Package MUST contain a Info- While legacy INFO usage has been widely adopted for specific
Package header field. An INFO request without an Info-Package header application use cases, [RFC2976] did not define a mechanism for SIP
field MUST NOT contain an Info-Package header field, and the request UAs to indicate for which types of applications and contexts they
SHALL be interpreted as being a legacy INFO usage request. support the INFO method. In addition, [RFC2976] did not provide a
mechanism to explicitly indicate the type of application and context
for which a specific INFO message is associated.
Example: If the Content-Type is "image/jpeg", the MIME-attached
content is a JPEG image. Still, there are many useful ways a UA can
render an image. The image could be a caller-id picture, a contact
icon, a photo for sharing, and so on. The sender does not know which
image to send to the receiver if the receiver supports an image
content type. Likewise, the receiver does not know the context of an
image the client is sending if the receiver supports receiving more
than one image content type.
Since legacy INFO usages do not have associated Info Packages, it 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 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
field to indicate for which legacy INFO usage an INFO request is
associated with.
Due to the problems described above, legacy INFO usages often require
static configuration about for what type of applications and contexts
UAs support the INFO method, and the way they handle application
information transported in INFO messages. That has caused
interoperability problems in the industry. Therefore, a need for a
well defined and documented description of what the information sent
in the INFO is used for has been identified. This situation is
analogous to the context issue in Internet Mail [RFC3458].
9.3. Co-existence with Info Package based INFO usage
As described in Section 4, an INFO request associated with an Info
Package always contains an Info-Package header field. A legacy INFO
request MUST NOT contain an Info-Package header field.
UAs are allowed to enable both legacy INFO usages and Info Package UAs are allowed to enable both legacy INFO usages and Info Package
usages as part of the same session. usages as part of the same invite dialog usage.
7. Info Package Requirements See Appendix A for examples of existing legacy INFO usages.
7.1. General 10. Info Package Requirements
10.1. General
This Section provides guidance on how to define an Info Package, and This Section provides guidance on how to define an Info Package, and
what information needs to be provided. what information needs to be provided.
If an Info Package extends or modifies the behavior described in this If an Info Package extends or modifies the behavior described in this
document, it MUST be described in the definition for that Info document, it MUST be described in the definition for that Info
Package. Info Package definitions SHOULD NOT repeat procedures Package. Info Package definitions should not repeat procedures
defined in this specification, unless needed for clarification or defined in this specification, unless needed for clarification or
emphasis purpose. emphasis purpose.
Info Packages MUST NOT weaken any behavior designated with "SHOULD" Info Packages MUST NOT weaken any behavior designated with "SHOULD"
or "MUST" in this specification. However, Info Packages MAY or "MUST" in this specification. However, Info Packages MAY
strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST"
strength if applications associated with the Info Package requires strength if applications associated with the Info Package requires
it. it.
Info Package definitions SHALL address the issues defined in the Info Package definitions SHALL address the issues defined in the
following subsections, unless an issue is not applicable for the following subsections, or document why an issue is not applicable for
specific Info Package. the specific Info Package.
7.2. Applicability 10.2. 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 transport application back-to-back User Agents (B2BUAs) to see the transported application
information, or that it is seen unfeasible to establish separate information (which would not be the case if the information was
dialogs (subscription) for transporting the information. transported on a media path), or that it is not seen feasible to
establish separate dialogs (subscription) in order to transport the
information.
Annex A provides more information, and describes alternative Annex A provides more information, and describes alternative
mechanisms which one should consider for solving the specific use- mechanisms which one should consider for solving a specific use-case.
case.
7.3. Info Package Name 10.3. Info Package Name
The Info Package specification MUST define an Info Package name. The Info Package specification MUST define a for Info Package name
(e.g. "Info Package for X").
The specification MUST also define the header field value to be used The specification MUST also define the header field value (e.g.
to indicate support of this package in the Recv-Info and Info-Package "infoX") to be used to indicate support of this package in the Recv-
header fields. The header field value MUST conform to the ABNF Info and Info-Package header fields. The header field value MUST
defined in Section 8.2. conform to the ABNF defined in Section 8.2.
The specification MUST also include the information that appears in The specification MUST also include the information that appears in
the IANA registration of the token. For information on registering the IANA registration of the token. For information on registering
such types, see Section **9. such types, see Section 9.
7.4. Info Package Parameters 10.4. 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 representing the Info Package. together with the header field value representing the Info Package.
The specification MUST describe the syntax and semantics of the The specification MUST describe the syntax and semantics of the
parameters. It MUST be specified whether a specific parameter is parameters. It MUST be specified whether a specific parameter is
only applicable to the Recv-Info header, the Info-Package header, or only applicable to the Recv-Info header, the Info-Package header, or
both. both.
Note that Info Package parameters are only applicable for the Info Note that Info Package parameters are only applicable for the Info
Package(s) for which they have been explicitly defined. If used for Package(s) for which they have been explicitly defined. They MUST
other Info Packages they MUST be discarded. NOT be used for other Info Packages.
7.5. SIP Option Tags NOTE: Info Package parameters defined for specific Info Packages may
share the name with parameters defined for other Info Packages, but
the parameter semantics are specific to the Info Package for which
they are defined.
10.5. SIP Option Tags
The Info Package specification MAY define SIP option tags, which can The Info Package specification MAY define SIP option tags, which can
be used as described in [RFC3261]. be used as described in [RFC3261].
SIP option tags MUST conform to the SIP Change Process [RFC3427]. SIP option tags MUST conform to the SIP Change Process
[I-D.peterson-rai-rfc3427bis].
7.6. INFO Message Bodies 10.6. INFO Message Bodies
The Info Package specification MUST define what type of message The Info Package specification MUST define what type of message body
bodies, if any, are associated with the Info Package, and MUST refer parts are associated with the Info Package, and MUST refer to
to specifications where the syntax, semantics and MIME type of the specifications where the syntax, semantics and MIME type of the
message body is described. message body parts are described.
7.7. Info Package Usage Restrictions If multiple body parts are used with an Info Package, the Info
Package specification MUST define whether there are special rules on
how the body parts are to be inserted in multipart body parts, and
what types of multipart to use.
10.7. Info Package Usage Restrictions
The Info Package specification MUST define whether a UA is allowed to The Info Package specification MUST define whether a UA is allowed to
send overlapping (outstanding) INFO requests associated with the Info send overlapping (outstanding) INFO requests associated with the Info
Package, or whether the UA has to wait for the response for a Package, or whether the UA has to wait for the response for a
previous INFO request associated with the same Info Package. previous INFO request associated with the same Info Package.
The specification MUST define whether there SIP level restrictions in The specification MUST define whether there are SIP level
the usage of the Info Package. For example, an Info Package may restrictions in the usage of the Info Package. For example, an Info
require support of other SIP extensions (e.g. reliable provisional Package may require support of other SIP extensions (e.g. reliable
responses). provisional responses).
The specification MUST define whether there are restrictions on The specification MUST define whether there are restrictions on
indicating support of, or using, the Info Package together with other indicating support of, or using, the Info Package together with other
Info Packages. Info Packages.
If Info Package restrictions are violated (i.e. if overlapping INFO As the SIP stack may not be aware of Info Package specific
requests are not allowed for an Info Package, but a UA still receives restrictions, it cannot be assumed that overlapping requests would be
overlapping requests), the UA MUST NOT reject such requests. Instead rejected. As defined in Section 4.4, in most cases a 200 OK response
the application logic associated with the Info Package MUST handle will be sent for the INFO request. The application logic associated
such situations. with the Info Package needs to handle situations which can occur due
to overlapping requests.
7.8. Rate of INFO Requests 10.8. Rate of INFO Requests
The Info Package specification MUST a maximum rate at which INFO The Info Package specification MUST specify a maximum rate at which
requests associated with the specific Info Package can be generated INFO requests associated with the specific Info Package can be
by a UA in a dialog. generated by a UA in a dialog.
The specification MAY define Info Package parameters to be used for The specification MAY define Info Package parameters to be used for
indicating or negotiating the INFO request rate. Alternatively the indicating or negotiating the INFO request rate. Alternatively the
rate information can be included in the application information rate information can be included in the application information
associated with the Info Package. associated with the Info Package.
7.9. IANA Registrations 10.9. IANA Registrations
The Info Package specification MUST contain an IANA Considerations The Info Package specification MUST contain an IANA Considerations
section that includes definitions for the Info Package Name and, if section that includes definitions for the Info Package Name and, if
needed, supported MIME types. needed, supported MIME types.
7.10. Security Considerations 10.10. Info Package Security Considerations
If the application information associated with the Info Package If the application information associated with the Info Package
requires certain level of security, the Info Package specification requires certain level of security, the Info Package specification
MUST describe the mechanisms to be used in order to provide the MUST describe the mechanisms to be used in order to provide the
required security. required security.
Otherwise, even if no additional security than what is provided for Otherwise, even if no additional security than what is provided for
the underlying SIP protocol is needed, it SHALL be stated in the Info the underlying SIP protocol is needed, this fact SHALL be stated in
Package specification. the Info Package specification.
NOTE: In some cases, it may not be sufficient to mandate TLS in order NOTE: In some cases, it may not be sufficient to mandate TLS in order
to secure the Info Package payload, since intermediaries will have to secure the Info Package payload, since intermediaries will have
access to the payload and past the first hop, there is no way to access to the payload, and beyond the first hop, there is no way to
assure subsequent hops will not forwards the payload in clear text. assure subsequent hops will not forwards the payload in clear text.
The best way to ensure secure transport at the application level is The best way to ensure secure transport at the application level is
to have the security at the application level. The most common to have the security at the application level. One way of achieving
method of achieving this is to use end-to-end security techniques this is to use end-to-end security techniques such as S/MIME
such as S/MIME [RFC3851]. [RFC3851].
7.11. Application Procedures 10.11. Application Procedures
The Info Package specification SHOULD contain a description of the The Info Package specification SHOULD contain a description of the
application procedures associated with the Info Package, or application procedures associated with the Info Package, or
alternatively refer to application procedures defined elsewhere. alternatively refer to application procedures defined elsewhere.
7.12. Examples 10.12. Examples
It is RECOMMENDED that Info Package specifications include It is recommended that Info Package specifications include
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 MUST NOT Note that example flows are by definition informative, and do not
replace normative text replace normative text
8. Syntax 11. IANA Considerations
8.1. General
This Section describes the syntax extensions required for the INFO
method. The previous sections describe the semantics. Note the
formal syntax definitions described in this document use the ABNF
format used in [RFC3261] and contain references to elements defined
therein.
8.2. ABNF
INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON Info-package-list
Info-package-list = "nil"
/ Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( ";" Info-package-param)
Info-package-name = token
Info-package-param = generic-param
NOTE on the Recv-Info production: if the header field value is "nil",
the header field MUST NOT contain any other Info Packages, and the
SIP message MUST NOT contain more than one Recv-Info header field.
9. IANA Considerations
9.1. Update to Registration of SIP INFO Method 11.1. Update to Registration of SIP INFO Method
Please update the existing registration in the SIP Methods and Please update the existing registration in the SIP Methods and
Response Codes registry under the SIP Parameters registry that Response Codes registry under the SIP Parameters registry that
states: states:
Method: INFO Method: INFO
Reference: [RFC2976] Reference: [RFC2976]
to: to:
Method: INFO Method: INFO
Reference: [RFCXXXX] Reference: [RFCXXXX]
9.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 Please add the following new SIP header field in the Header Fields
subregistry under the SIP Parameters registry. subregistry under the SIP Parameters registry.
Header Name: Info-Package Header Name: Info-Package
Compact Form: (none) Compact Form: (none)
Reference: [RFCXXXX] Reference: [RFCXXXX]
9.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 Please add the following new SIP header field in the Header Fields
subregistry under the SIP Parameters registry. subregistry under the SIP Parameters registry.
Header Name: Recv-Info Header Name: Recv-Info
Compact Form: (none) Compact Form: (none)
Reference: [RFCXXXX] Reference: [RFCXXXX]
9.4. Creation of the Info Packages Registry 11.4. Creation of the Info Packages Registry
Please create a subregistry in the SIP Parameters registry for Info Please create a subregistry in the SIP Parameters registry for Info
Packages. This subregistry has a modified First Come First Served Packages. This subregistry has a modified First Come First Served
[RFC5226] policy. [RFC5226] policy.
The following data elements populate the Info Package Registry. The following data elements populate the Info Package Registry.
o Info Package Name: The Info Package Name is a case-sensitive o Info Package Name: The Info Package Name is a case-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 Info Package Parameters: The Info Package Parameters are case- o Info Package Parameters: The Info Package Parameters are case-
skipping to change at page 21, line 4 skipping to change at page 23, line 32
[RFC5226] policy. [RFC5226] policy.
The following data elements populate the Info Package Registry. The following data elements populate the Info Package Registry.
o Info Package Name: The Info Package Name is a case-sensitive o Info Package Name: The Info Package Name is a case-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 Info Package Parameters: The Info Package Parameters are case- o Info Package Parameters: The Info Package Parameters are case-
sensitive tokens. Info Package Parameters are only applicable to sensitive tokens. Info Package Parameters are only applicable to
the Info Package for which they are defined, so the same Info the Info Package for which they are defined, so the same Info
Package Parameter Names may exist for different Info Packages. Package Parameter Names may exist for different Info Packages.
o Info Package Payload MIME Types: A list of zero or more registered o Info Package Payload MIME Types: A list of zero or more registered
MIME types from the MIME Type Registry. MIME types from the MIME Type Registry.
o Standards Status: Values are "Standards Track" or empty. See o Standards Status: Values are "Standards Track" or empty. See
below for a discussion and rules on this field. below for a discussion and rules on this field.
o Reference: If there is a published specification describing the o Reference: If there is a published specification describing the
Info Package, place a reference to that specification in this Info Package, place a reference to that specification in this
column. See below for a discussion on this field. column. See below for a discussion on this field.
If there is a published specification, the registration MUST include If there is a published specification, the registration must include
a reference to such specification. The Standards Status field is an a reference to such specification. The Standards Status field is an
indicator of the level of community review for the Info Package indicator of the level of community review for the Info Package
specification. If the specification meets the requirements for specification. If the specification meets the requirements for
Specification Required [RFC5226], the value for the Standards Status Specification Required [RFC5226], the value for the Standards Status
field is "Standards Track". Otherwise, the field is empty. field is "Standards Track". Otherwise, the field is empty.
This document uses the Info Package Name "nil" to represent "no Info This document uses the Info Package Name "nil" to represent "no Info
Package present" and as such, IANA shall not honor a request to Package present" and as such, IANA shall not honor a request to
register the "nil" Info Package. register the "nil" Info Package.
The initial population of this table shall be: The initial population of this table shall be:
Name MIME Type Standards Status Reference Name MIME Type Standards Status Reference
nil Standards Track [RFCXXXX] nil Standards Track [RFCXXXX]
9.5. Registration of the Info-Package Content-Disposition 11.5. Registration of the Info-Package Content-Disposition
Please add the following registration to the Content-Disposition
registry. The description suitable for the IANA registry is as
follows.
The payload of the message carrying this Content-Disposition header Please add the following new header field value to the Content-
field value is the payload of an Info Package. Disposition registry.
Name: info-package
Description: the body contains information associated with an Info Package
Reference: RFCXXXX
9.6. SIP Response Code 469 Registration 11.6. SIP Response Code 469 Registration
Please register the 469 response code in the Session Initiation Please register the following new response code in the Session
Protocol Parameters - Response Codes registry as follows. Initiation Protocol Parameters - Response Codes registry.
Response Code: 469 Response Code: 469
Default Reason Phrase: Bad INFO Package Default Reason Phrase: Bad INFO Package
Reference: RFCXXXX Reference: RFCXXXX
10. Examples 12. Examples
10.1. Simple Info Package 12.1. Indication of which Info Packages UAs are willing to receive INFO
requests within an invite dialog usage
The UAC sends an INVITE request, where the UAC indicates that it is
willing to receive Info Packages P and R.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Recv-Info: P, R
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: ...
...
The UAS sends a 200 OK response back to the UAC, where the UAS
indicates that it is willing to receive Info 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:alice@pc33.example.com>
Recv-Info: R, T
Content-Type: application/sdp
Content-Length: ...
...
The UAC sends ACK.
ACK sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 ACK
Content-Length: 0
12.2. INFO request with information associated with a simple Info
Package
Here Alice sends Bob a simple Info Package payload. Here Alice sends Bob a simple Info Package payload.
INFO sip:alice@192.0.2.1 SIP/2.0 INFO sip:alice@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567 To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix Call-Id: 123456mcmxcix
CSeq: 2 INFO CSeq: 2 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
10.2. Multipart INFO Example 12.3. Multipart INFO Example
Other SIP extensions can put payloads into an INFO method, Other SIP extensions can sometimes add payload body parts into an
independent of the Info Package. In this case, the Info Package INFO request, independent of the Info Package. In this case, the
payload gets put into a Multipart MIME body, with the content Info Package payload gets put into a Multipart MIME body, with a
disposition indicating which body belongs to the Info Package. Since Content-Disposition header field that indicates which body part is
there is one and only one Info Package payload in the message, we associated with the Info Package.
only need to tag which body part goes with the Info Package.
INFO sip:alice@192.0.2.1 SIP/2.0 INFO sip:alice@192.0.2.1 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567 To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: 123456mcmxcix Call-Id: 123456mcmxcix
CSeq: 7 INFO CSeq: 7 INFO
Info-Package: foo Info-Package: foo
mumble-extension: <cid:abcd9999qq> mumble-extension: <cid:abcd9999qq>
Content-Type: multipart/mixed;boundary="theboundary" Content-Type: multipart/mixed;boundary="theboundary"
skipping to change at page 23, line 31 skipping to change at page 26, line 33
<mumble stuff> <mumble stuff>
--theboundary --theboundary
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
--theboundary-- --theboundary--
11. Modifications to SIP Change Process 13. Security Considerations
By eliminating multiple uses of INFO messages without adequate By eliminating multiple usages of INFO messages without adequate
community review and by eliminating the possibility for rogue SIP UAs community review and by eliminating the possibility for rogue SIP UAs
from confusing another User Agent by purposely sending unrelated INFO from confusing another UA by purposely sending unrelated INFO
requests, we expect this document's clarification of the use of INFO requests, we expect this document's clarification of the use of INFO
to improve the security of the Internet. Whilst rogue UAs can still to improve the security of the Internet. Whilst rogue UAs can still
send unrelated INFO requests, this framework provides mechanisms for send unrelated INFO requests, this mechanism provides mechanisms for
which the UAS and other security devices can filter for approved Info which the UAS and other security devices can filter for approved Info
Packages. Packages.
If the content of the Info Package payload is private, User Agents If the content of the Info Package payload is private, UAs will need
will need to use end-to-end encryption, such as S/MIME, to prevent to use end-to-end encryption, such as S/MIME, to prevent access to
access to the content. This is particularly important as transport the content. This is particularly important as transport of INFO is
of INFO is likely not to be end-to-end, but through SIP proxies and likely not to be end-to-end, but through SIP proxies and back-to-back
back-to-back user agents (B2BUA's), which the user may not trust. user agents (B2BUA's), which the user may not trust.
The INFO mechanism 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 INFO messages may require a higher level of
protection than the underlying SIP-based session signaling. In protection than the underlying SIP dialog signaling. In particular,
particular, if one does not protect the SIP signaling from if one does not protect the SIP signaling from eavesdropping or
eavesdropping or authentication and repudiation attacks, for example authentication and repudiation attacks, for example by using TLS
by using TLS transport, then the INFO request and its contents will transport, then the INFO request and its contents will be vulnerable,
be vulnerable, as well. Even with SIP/TLS, any SIP hop along the as well. Even with SIP/TLS, any SIP hop along the path from UAC to
path from UAC to UAS can view, modify, or intercept INFO requests, as UAS can view, modify, or intercept INFO requests, as they can with
they can with any SIP request. This means some applications may any SIP request. This means some applications may require end-to-end
require end-to-end encryption of the INFO payload, beyond, for encryption of the INFO payload, beyond, for example, hop-by-hop
example, hop-by-hop protection of the SIP signaling itself. Since protection of the SIP signaling itself. Since the application
the application dictates the level of security required, individual dictates the level of security required, individual Info Packages
Info Packages have to enumerate these requirements. In any event, have to enumerate these requirements. In any event, the Info Package
the Info Package mechanism described by this document provides the mechanism described by this document provides the tools for such
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 use is one can reuse the
same digest-challenge mechanism used for INVITE based authentication same digest-challenge mechanism used for INVITE based authentication
for the INFO request. For example, one could use a quality-of- for the INFO request. For example, one could use a quality-of-
protection (qop) value of authentication with integrity (auth-int), protection (qop) value of authentication with integrity (auth-int),
to challenge the request and its body, and prevent intermediate to challenge the request and its body, and prevent intermediate
devices from modifying the body. However this assumes the device devices from modifying the body. However this assumes the device
which knows the credentials in order to perform the INVITE challenge which knows the credentials in order to perform the INVITE challenge
is still in the path for the INFO, or that the far-end UAS knows such is still in the path for the INFO, or that the far-end UAS knows such
credentials. credentials.
12. References 14. References
12.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", RFC 2119, BCP 14, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[I-D.ietf-sip-body-handling] [RFC5621] Camarillo, G., "Message Body Handling in the Session
Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009.
Initiation Protocol (SIP)",
draft-ietf-sip-body-handling-06 (work in progress),
March 2009.
12.2. Informative References 14.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000. October 2000.
[RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
"Interworking between the Session Initiation Protocol "Interworking between the Session Initiation Protocol
(SIP) and QSIG", BCP 117, RFC 4497, May 2006. (SIP) and QSIG", BCP 117, RFC 4497, May 2006.
skipping to change at page 25, line 39 skipping to change at page 28, line 39
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)", Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004. BCP 85, RFC 3725, April 2004.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
and B. Rosen, "Change Process for the Session Initiation "Indicating User Agent Capabilities in the Session
Protocol (SIP)", BCP 67, RFC 3427, December 2002. Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures", for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002. BCP 63, RFC 3372, September 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
skipping to change at page 26, line 42 skipping to change at page 29, line 42
[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.
[I-D.peterson-rai-rfc3427bis]
Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP)",
draft-peterson-rai-rfc3427bis-03 (work in progress),
September 2009.
[W3C.REC-voicexml21-20070619] [W3C.REC-voicexml21-20070619]
Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter, McGlashan, S., Lee, A., Carter, J., Porter, B., Auburn,
J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke, R., Oshry, M., Rehor, K., Bodell, M., Burke, D., Baggia,
D., Candell, E., and R. Auburn, "Voice Extensible Markup P., Candell, E., and D. Burnett, "Voice Extensible Markup
Language (VoiceXML) 2.1", World Wide Web Consortium Language (VoiceXML) 2.1", World Wide Web Consortium
Recommendation REC-voicexml21-20070619, June 2007, Recommendation REC-voicexml21-20070619, June 2007,
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>. <http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[I-D.ietf-speechsc-mrcpv2] [I-D.ietf-speechsc-mrcpv2]
Shanmugham, S. and D. Burnett, "Media Resource Control Shanmugham, S. and D. Burnett, "Media Resource Control
Protocol Version 2 (MRCPv2)", Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-19 (work in progress), draft-ietf-speechsc-mrcpv2-20 (work in progress),
June 2009. August 2009.
[I-D.saleem-msml] [I-D.saleem-msml]
Sharratt, G. and A. Saleem, "Media Server Markup Language Saleem, A. and G. Sharratt, "Media Server Markup Language
(MSML)", draft-saleem-msml-08 (work in progress), (MSML)", draft-saleem-msml-09 (work in progress),
February 2009. July 2009.
Appendix A. Info Package Considerations
A.1. General
This section covers considerations to take into account when deciding
whether the usage of an Info Package is appropriate for transporting
of application information for a specific use-case.
A.2. Appropriateness of Info Package Usage
When designing an Info Package, for application level information
exchange, it is important to consider: is signaling, using INFO
requests, within a SIP session, an appropriate mechanism for the use-
case? Is it because it is the most reasonable and appropriate
choice, or merely because "it's easy"? Choosing an inappropriate
mechanism for a specific use-case can cause negative effects in SIP
networks where the mechanism is used.
A.3. Dialog Fate Sharing
As described in [RFC5057], an INFO request is always part of an
INVITE dialog usage.
One needs to consider the fate of the dialog usage of an INFO request
is rejected. In some cases it may be acceptable that the whole
dialog useage is terminated, while in other cases is is desirable to
maintain the dialog usage.
A.4. INFO Request Rate and Volume
There is no default throttling mechanism for INFO requests. Apart
from the session establishment, the number of SIP messages exchanged
during a normal SIP session is rather small.
Some applications, like sending of DTMF tones, can generate a burst
of up to 20 messages per second. Other applications, like constant
GPS location updates, could generate a high rate of INFO requests
during the whole session.
Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
exchange of bulk data beyond these limits, especially if the headers
plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for
such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user
plane data transport mechanisms.
A.5. Alternative Mechanisms
A.5.1. Alternative SIP signaling plane mechanisms
A.5.1.1. General
This subsection describes some alternative mechanisms for
transporting application information on the SIP signaling plane,
using SIP messages.
A.5.1.2. SUBSCRIBE/NOTIFY
An alternative for application level interaction is SIP Events, also
known as SUBSCRIBE/NOTIFY [RFC3265]. In this model, a user agent
requests state information, such as key pad presses from a device to
an application server or key map images from an application server to
a device.
A SUBSCRIBE requests creates a new session, and a subscription dialog
usage [RFC5057], which is separate, and does not share the fate any
other sessions.
The subscription mechanism can be used by SIP entities to receive
state information about SIP sessions, without requiring the entities
to be part of the route set of those sessions.
As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies
and B2BUAs, the resource impact caused by the subscription sessions
needs to be considred. The number of subscription sessions per user
also needs to be considered.
As for any other SIP signaling plane based mechanism for transporting
application information, the SUBSCRIBE/NOTIFY messages can put a
significant burden on intermediate SIP entities which are part of the
session route set, but do not have any interest in the application
information transported between the end users.
A.5.1.3. MESSAGE
The MESSAGE method [RFC3428] defines one-time instant message
exchange, typically for sending MIME contents for rendering to the
user.
A.5.2. Media Plane Mechanisms
A.5.2.1. General
In SIP, media plane channels associated with SIP sessions are
established using SIP signaling, but the data exchanged on the media
plane channel does not traverse SIP signaling intermediates, so if
there will be a lot of information exchanged, and there is no need
for the SIP signaling intermediates routing to examine the
information, it is recommended to use a media plane mechanism, rather
than a SIP signaling based.
A low latency requirement for the exchange of information is one
strong indicator for using a media channel. Exchanging information
through the SIP routing network can introduce hundreds of
milliseconds of latency.
A.5.2.2. MRCPv2
One mechanism for media plane exchange of application data is MRCPv2
[I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented
channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream is
established.
A.5.2.3. MRSP
MSRP [RFC4975] defines session-based instant messaging as well as
bulk file transfer and other such large-volume uses.
A.5.3. Non-SIP related mechanisms [Ecma-355]
"Standard ECMA-355 Corporate Telecommunication Networks -
Tunnelling of QSIG over SIP", ECMA http://
www.ecma-international.org/publications/standards/
Ecma-355.htm, June 2008.
Another alternative is to use a totally externally signaled channel, Appendix A. Legacy INFO Usages
such as HTTP [RFC2616]. In this model, the user agent knows about a
rendezvous point to direct HTTP requests to for the transfer of
information. Examples include encoding of a prompt to retrieve in
the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target
in a VoiceXML [W3C.REC-voicexml21-20070619] script.
Appendix B. Legacy INFO Usages A.1. General
We do not intend this section to be a comprehensive catalog of INFO This section provides examples of existing legacy INFO usages. This
usages. However, it should give the reader a flavor for current INFO section is not meant to be a comprehensive catalog of legacy INFO
usages. usages, but it should give the reader a flavor for current legacy
INFO usages.
B.1. ISUP A.2. ISUP
SIP-T uses Content-Type to identify ISUP protocol elements in an INFO [RFC3372] specifies the encapsulation of ISUP in SIP message bodies.
message. See RFC3372 [RFC3372]. ITU-T and 3GPP have specified similar procedures.
B.2. QSIG A.3. QSIG
QSIG uses Content-Type to identify QSIG protocol elements in an INFO [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies.
message. See RFC4497 [RFC4497].
B.3. MSCML A.4. MSCML
MSCML uses a Require to ensure the UAS understands that INFO messages [RFC5022] specifies how INFO is used as a transport mechanism by the
of the MSCML type are in fact MSCML messages. See RFC5022 [RFC5022]. MSCML protocol. MSCML uses an option-tag in the Require header field
to ensure that the receiver understands the INFO content.
B.4. MSML A.5. MSML
MSML endpoints just know the INFO messages carry MSML and from the [I-D.saleem-msml] specifies how INFO us used as a transport mechanism
Content-Type of the given INFO method request. See the MSML by the MSML protocol.
[I-D.saleem-msml] draft.
B.5. Video Fast Update A.6. Video Fast Update
Microsoft, Polycom, and Radvision used INFO messages as an interim Companies have been using INFO messages in order to request fast
solution for requesting fast video update before the ability to video update. Currently a standardized mechanism, based on RTCP, has
request I-Frames in RTCP was available. See the XML Schema for Media been specified in [RFC5168]
Control [RFC5168] for more information.
Appendix C. Acknowledgements Appendix B. Acknowledgements
We are standing on the shoulders of giants. Jonathan Rosenberg did The work on this document was influenced by the "INFO Considered
the original "INFO Considered Harmful" Internet Draft on 26 December Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and
2002, which influenced the work group and this document. Likewise, by the "Packaging and Negotiation of INFO Methods for the Session
Dean Willis influenced the text from his Internet Draft, "Packaging Initiation Protocol" draft (15 January 2003) written by Dean Willis.
and Negotiation of INFO Methods for the Session Initiation Protocol"
of 15 January 2003. Four paragraphs come from Jonathan Rosenberg's
INFO Litmus draft. My, we have been working on this for a long time!
This and other related drafts have elicited well over 450 messages on The following individuals have been involved in the work, and have
the SIP list. People who have argued with its thesis, supported its provided input and feedback on this document:
thesis, added to the examples, or argued with the examples, include Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben
the following individuals: Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris
Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean
Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon
Camarillo, Gordon Beith, Henry Sinnreich, 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, Johnathan
Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, Rosenberg, Juha Heinanen, Gordon Beith, Keith Drage, Kevin Attard
Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael
Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain,
Robert Sparks, Roland Jesske, Salvatore Loreto, Sam Ganesan, Rayees Khan, Robert Sparks, Roland Jesske, Roni Evan Salvatore
Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve
Xavier Marjou. Langstaff, Sumit Garg and Xavier Marjoum.
John Elwell and Francois Audet helped with QSIG references. In John Elwell and Francois Audet helped with QSIG references. In
addition, Francois Audet provided actual text for the revised addition, Francois Audet provided text for the revised abstract.
abstract. Keith Drage gave lots of excellent comments and helped Keith Drage provided comments and helped immensely with Figure 1.
immensely with Figure 1.
The work group version of this document benefited from the close John Elwell and Robert Sparks provided valuable feedback during the
readings and comments from WGLC process, in order to prepare this document for publication.
John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale
Worley, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith,
Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary
Barnes, and Salvatore Loreto.
Since publication of the first work group version of this document, Appendix C. Change Log
we have had over 329 messages. New voices in addition to those
included above include
Arun Arunachalam, Christian Stredicke, Eric Rescorla, Inaki Baz
Castillo, and Roni Evan.
However, any errors and issues we missed are still our own. [RFC EDITOR NOTE: Please remove this section when publishing]
Appendix D. Change Log 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
[RFC EDITOR NOTE: Please remove this section when publishing] 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 allignment
o Clarification or roles
Changes from draft-ietf-sip-info-events-03 Changes from draft-ietf-sip-info-events-03
o Clarified Abstract language o Clarified Abstract language
o All SIP dialogs are now refered to as sessions o All SIP dialogs are now refered to as sessions
o Clarified the image example in the Introduction o Clarified the image example in the Introduction
o Clarified the relationship (none) between SIP Event Packages and o Clarified the relationship (none) between SIP Event Packages and
SIP Info Packages SIP Info Packages
o Really, really clarified the protocol is NOT a negotiation but an o Really, really clarified the protocol is NOT a negotiation but an
advertisement advertisement
o Split Section 3 into UAS and UAC behavior o Split Section 3 into UAS and UAC behavior
 End of changes. 154 change blocks. 
712 lines changed or deleted 774 lines changed or added

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