draft-ietf-sipcore-info-events-00.txt   draft-ietf-sipcore-info-events-01.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
Intended status: Standards Track C. Holmberg Expires: April 2, 2010 C. Holmberg
Expires: January 6, 2010 Ericsson Ericsson
July 5, 2009 September 29, 2009
Session Initiation Protocol (SIP) INFO Method and Package Framework Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sipcore-info-events-00 draft-ietf-sipcore-info-events-01
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 January 6, 2010. This Internet-Draft will expire on April 2, 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 provides new semantics for the SIP INFO method of RFC
2976. These new semantics defined here are fully backwards 2976. These new semantics defined here are fully backwards
compatible with the old semantics. Core to the new semantics is a compatible with the old semantics. Core to the new semantics is a
mechanism for defining, negotiating and exchanging Info Packages that mechanism for defining, indicating support of, and exchanging Info
use the INFO method. Applications that need to exchange session- Packages that use the INFO method. Applications that need to
related information within a SIP INVITE-created session, also known exchange application information within a SIP invite usage dialog
as application level information, use these INFO requests. This (RFC 5057), can use these Info Packages. This document replaces RFC
draft addresses issues and open items from RFC 2976 and replaces it. 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].
Be aware this document strictly follows RFC 3261 [RFC3261] for the
definition of the terms User Agent Server (UAS) and User Agent Client
(UAC). Specifically, the UAC issues a SIP request and the UAS
responds. This terminology may be confusing when one combines the
INFO case with the INVITE case. For an INVITE, the initiator of the
session is the UAC and the target of the session is the UAS.
However, it is possible for the target UA of the session, the UAS of
the INVITE transaction, to send an INFO to the initiating UA of the
session, the UAC of the INVITE transaction. From the perspective of
the INFO, the target UA of the session (INVITE UAS) is, in fact, the
UAC (sender) of the INFO request. Likewise, from the perspective of
the INFO, the initiating UA of the session (INVITE UAC) is the UAS
(recipient) of the INFO request. Since this document strictly
follows RFC 3261, we refer to the UA that issues the INVITE as the
"initiating UA" and the UA that responds to the INVITE as the "target
UA" to remove any confusion.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Info Package Behavior . . . . . . . . . . . . . . . . . . . . 7 3. Info Package Support . . . . . . . . . . . . . . . . . . . . . 7
3.1. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. User Agent Behavior . . . . . . . . . . . . . . . . . . . 7
3.3. Package Versions . . . . . . . . . . . . . . . . . . . . . 9 3.3. Package Versioning . . . . . . . . . . . . . . . . . . . . 8
3.4. Advertisement Example . . . . . . . . . . . . . . . . . . 10 3.4. REGISTER Processing . . . . . . . . . . . . . . . . . . . 8
4. The INFO Method Request . . . . . . . . . . . . . . . . . . . 11 3.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 8
4.1. INFO Requests . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. INFO Request Body . . . . . . . . . . . . . . . . . . . . 12 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Responses to the INFO Request Method . . . . . . . . . . . 13 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Routing Behavior . . . . . . . . . . . . . . . . . . . . . 14 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Behavior of Registrars . . . . . . . . . . . . . . . . . . 14 4.3. INFO Request Message Body . . . . . . . . . . . . . . . . 11
4.6. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 14 4.4. INFO Response . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Order of Delivery . . . . . . . . . . . . . . . . . . . . 15 4.5. INFO Response Message Body . . . . . . . . . . . . . . . . 12
5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 15 4.6. Order of Delivery . . . . . . . . . . . . . . . . . . . . 12
5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 15 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 13
5.2. INFO Headers . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Info-Package header . . . . . . . . . . . . . . . . . 17 5.2. INFO Header Fields . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Recv-Info header . . . . . . . . . . . . . . . . . . . 18 5.2.1. Info-Package header field . . . . . . . . . . . . . . 15
6. Legacy Uses of INFO . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Recv-Info header field . . . . . . . . . . . . . . . . 15
7. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 6. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 19 7. Info Package Requirements . . . . . . . . . . . . . . . . . . 16
7.2. Info Package Name . . . . . . . . . . . . . . . . . . . . 19 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Info Package Parameters . . . . . . . . . . . . . . . . . 19 7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Info Package Tags . . . . . . . . . . . . . . . . . . . . 19 7.3. Info Package Name . . . . . . . . . . . . . . . . . . . . 17
7.5. INFO Bodies . . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Info Package Parameters . . . . . . . . . . . . . . . . . 17
7.6. UAC generation of INFO requests . . . . . . . . . . . . . 20 7.5. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 17
7.7. UAS processing of INFO requests . . . . . . . . . . . . . 20 7.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 17
7.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 21 7.7. Info Package Usage Restrictions . . . . . . . . . . . . . 17
7.9. IANA Registrations . . . . . . . . . . . . . . . . . . . . 21 7.8. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 18
7.10. Security Considerations . . . . . . . . . . . . . . . . . 21 7.9. IANA Registrations . . . . . . . . . . . . . . . . . . . . 18
7.11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.10. Security Considerations . . . . . . . . . . . . . . . . . 18
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.11. Application Procedures . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Update to Registration of SIP INFO Method . . . . . . . . 22 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Registration of the Info-Package Header Field . . . . . . 22 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.3. Registration of the Recv-Info Header Field . . . . . . . . 23 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.4. Creation of the Info Packages Registry . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.5. Registration of the Info-Package Content-Disposition . . . 24 9.1. Update to Registration of SIP INFO Method . . . . . . . . 20
9.6. SIP Response Code 469 Registration . . . . . . . . . . . . 24 9.2. Registration of the Info-Package Header Field . . . . . . 20
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.3. Registration of the Recv-Info Header Field . . . . . . . . 20
10.1. Simple Info Package . . . . . . . . . . . . . . . . . . . 24 9.4. Creation of the Info Packages Registry . . . . . . . . . . 20
10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 24 9.5. Registration of the Info-Package Content-Disposition . . . 21
11. Modifications to SIP Change Process . . . . . . . . . . . . . 25 9.6. SIP Response Code 469 Registration . . . . . . . . . . . . 21
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Simple Info Package . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 27 11. Modifications to SIP Change Process . . . . . . . . . . . . . 23
Appendix A. Info Package Considerations . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
A.2. Dialog Fate-Sharing . . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . . 25
A.3. Messaging Rates and Volume . . . . . . . . . . . . . . . . 30 Appendix A. Info Package Considerations . . . . . . . . . . . . . 27
A.4. Is there a better alternative? . . . . . . . . . . . . . . 30 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.5. Alternatives for Common INFO Use . . . . . . . . . . . . . 32 A.2. Appropriateness of Info Package Usage . . . . . . . . . . 27
A.5.1. State Updates . . . . . . . . . . . . . . . . . . . . 32 A.3. Dialog Fate Sharing . . . . . . . . . . . . . . . . . . . 27
A.5.2. User Stimulus: Touch Tones and Others . . . . . . . . 32 A.4. INFO Request Rate and Volume . . . . . . . . . . . . . . . 27
A.5.3. Direct Signaling Channel . . . . . . . . . . . . . . . 33 A.5. Alternative Mechanisms . . . . . . . . . . . . . . . . . . 28
A.5.4. Proxy-Aware Signaling . . . . . . . . . . . . . . . . 33 A.5.1. Alternative SIP signaling plane mechanisms . . . . . . 28
A.5.5. Dialog Probe . . . . . . . . . . . . . . . . . . . . . 33 A.5.2. Media Plane Mechanisms . . . . . . . . . . . . . . . . 29
A.5.6. Malicious Indicator . . . . . . . . . . . . . . . . . 34 A.5.3. Non-SIP related mechanisms . . . . . . . . . . . . . . 29
Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 34 Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 29
B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.5. Video Fast Update . . . . . . . . . . . . . . . . . . . . 35 B.5. Video Fast Update . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 35 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The SIP protocol [RFC3261] defines session control messages used to [RFC3261] defines a mechanism to setup and tear down SIP sessions. A
setup and tear down a SIP controlled session. In addition, a SIP SIP User Agent (UA) can use the re-INVITE and UPDATE methods during a
User Agent (UA) can use the re-INVITE and UPDATE methods during a session to change characteristics of the session, including media
session to change the characteristics of the session. Most often, properties, target information or properties related to the SIP
this is to change the properties of media flows related to the session timer mechanism [RFC4028].
session or to update the SIP session timer [RFC4028]. The purpose of
the INFO message [RFC2976] is to carry application level information
along the SIP signaling path. Note the INFO method does not change
the SIP session state. It may, however, change application state for
applications using the SIP session.
While INFO has been widely adopted for specific application use The purpose of the INFO message [RFC2976] is to carry application
cases, such as ISUP and DTMF exchange, RFC 2976 [RFC2976] neither level information between endpoints, using the SIP session signaling
defined a negotiation mechanism nor a means by which to explicitly path. Note that the INFO method is not used to update
indicate the type of application information contained in the INFO characteristics of the SIP session, but to allow the applications
message. This led to problems associated with static configuration. which use the SIP session to exchange information.
In addition, the industry realized there was a potential for
interoperability problems due to undefined content syntax and
semantics. This draft addresses these deficiencies and provides a
framework for explicit negotiation of capabilities and content
context using "Info Packages".
The INFO method as defined by RFC 2976 did not provide any context While the INFO method has been widely adopted for specific
for the information the request carried. While it may sometimes be application use cases, such as ISUP and DTMF exchange, [RFC2976] does
clear what the content is based on the Content-Type, this is only not define a mechanisms for SIP UAs to indicate what usages of INFO
true where there is only one contextual usage of the content-type. they support. In addition, [RFC2976] does not provide a mechanism to
For example, if the Content-Type is "image/jpeg", the MIME-attached explicitly indicate the type of application for which the INFO
content is a JPEG image. However, there are many useful ways a UAS message is used. In some cases it can be determined by the INFO
can render an image. Said differently, there are different contexts message body content, but not in a general way.
for an image in SIP. The image could be a caller-id picture, a
contact icon, a photo for sharing, and so on. The sender does not Example: If the Content-Type is "image/jpeg", the MIME-attached
know which image to send to the receiver if the receiver supports an content is a JPEG image. Still, there are many useful ways a UA can
image content type. Likewise, the receiver does not know the context render an image. The image could be a caller-id picture, a contact
of an image the client is sending if the receiver supports receiving icon, a photo for sharing, and so on. The sender does not know which
more than one image content type. Thus, we need a well defined and image to send to the receiver if the receiver supports an image
documented statement of what the information sent is for. This content type. Likewise, the receiver does not know the context of an
situation is identical to the context issue in Internet Mail image the client is sending if the receiver supports receiving more
[RFC3458]. RFC 3458 goes into this and other issues in detail. 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 Event Packages [RFC3265] perform the role of disambiguating the
context of a message for subscription-based events. This document context of a message for subscription-based events. The Info Package
provides a similar framework for INVITE-based application level mechanisms provides similar functionality for application information
information exchange. However, while the mechanism described here is exchange using invite dialog usages [RFC5057].
similar to subscription-based events, there is no formal relationship
between this mechanism and the subscription mechanism. In
particular, when a UAC issues a SUBSCRIBE, it creates a dialog usage.
The mechanism defined here creates neither a separate subscription Note that while Info Packages may be similar to subscription-based
dialog nor a subscription usage within an existing session. Instead, events, there is no formal relationship between this mechanism and
it uses the INVITE method and its responses to indicate supported the subscription mechanism.
Info Packages and the INFO method to convey the Info Packages.
Each UA enumerates which Info Packages it can receive. If a first UA The Info Package mechanism does not create a separate dialog usage.
indicates it can receive a package and a second UA can send the INFO messages are always part of, and share the fate of, an invite
package, the second UA can send INFO methods containing the payload dialog usage. INFO message can not be sent as part of other dialog
for that package. The Recv-Info header indicates which packages a UA usages, and they can not be sent outside an existing session.
is willing to receive. The Info-Package header indicates which
package a particular INFO method request belongs to. There is a
reserved Info Package, "nil", which indicates the UA conforms to this
document, but does not wish to receive Info Packages. This enables
other UAs that conform to this document to detect legacy UAs. A
legacy UA will not include a Recv-Info header in their SIP session
establishment or modification requests. Conversely, a UA that
supports Info Packages will have a Recv-Info header. Section 3
describes Info Package advertisement in detail.
This document does not describe any specific Info Package type If a UA supports the Info Package mechanism it indicates, using the
extensions. One must extend this protocol by other documents, herein Recv-Info header field which Info Packages it is willing to receive,
referred to as "Info Packages". Section 7 describes guidelines for on a per-session basis. A UA can indicate a new set of Info Packages
creating these extensions. at any time during the lifetime of the invite dialog usage of the
session. A UA can use a "nil" value to indicate that it is not
willing to receive any Info Packages at a certain moment, but that
the UA still supports the Info Package mechanism.
The INFO method does not change the state of SIP calls or the When a UA sends an INFO request, it uses the Info-Package header
parameters of the sessions SIP initiates. It merely sends optional field to indicate which Info Package is associated with the request.
application layer information, generally related to the session.
Applications need to be aware that application level information Section 3 describes the mechanism to indicate support of Info
transported by the INFO method constitutes mid-session signaling. Packages.
These messages traverse the post-session-setup SIP signaling path.
This is the path taken by SIP re-INVITEs, BYEs, and other SIP
requests within an individual session. SIP proxy servers will
receive, and potentially act on, mid-session signaling information.
Application designers need to understand this can be a feature, as
when the User Agents are exchanging information that elements in the
SIP signaling path need to be aware of. Conversely, this can be a
problem, as messages these network elements have no interest in can
also put a significant burden on those element's ability to process
other traffic. Moreover, such network elements may not be able to
read end-to-end encrypted INFO bodies.
2. Applicability Section 4 describes the usage of INFO messages.
This document replaces the SIP INFO method document [RFC2976] to Section 6 describes legacy usage of INFO, as defined in [RFC2976].
include explicit negotiation of supported Info Packages in the INVITE
transaction and indication of the Info Package to use by using a new
header field in the INFO request. As described in Section 4.1, the
mechanism described here is backwards compatible with legacy, RFC
2976 INFO mechanisms.
3. Info Package Behavior Section 7 describes guidelines on how to define Info Packages. This
document does not define any specific Info Packages.
As stated in the Conventions section, the term UAC refers to the UAC Annex A provides guidelines and issues to consider when deciding if
(sender) of the INFO method and UAS refers to the recipient of the usage of Info Packages is the most appropriate mechanism for a
INFO method. "Initiating UA" refers to the sender of an initial specific use-case.
INVITE to establish a session and "target UA" refers to the recipient
of that INVITE request.
3.1. UAS Behavior 2. Applicability
A UAS supporting this document MUST advertise the set of Info This document extends [RFC2976] to include a mechanism to in SIP
Packages it is willing to receive in Recv-Info header(s) in dialog messages explicitly indicate the supported Info Packages, and to
usage requests and responses for session establishment or target explicitly indicate what Info Package is associated with an INFO
refresh. This includes INVITE, UPDATE, PRACK, ACK, and their non- request. The mechanism is backward compatible with legacy usage of
failure responses (101-199 and 2xx only). INFO, as defined in [RFC2976], and allows such usage. New INFO
usages MUST use the mechanism defined in this document.
Once a UAS indicates support for an Info Package by sending a Recv- 3. Info Package Support
Info header with one or more package names, the UAS MUST be prepared
to receive an INFO containing that package. Note this may occur
before dialog negotiation completes.
Recall the UAC of an INVITE may choose to receive (be a UAS for) INFO 3.1. General
methods. This UA may chose not to offer any packages in the initial
INVITE and subsequently advertise packages from the target UA's
subsequent responses, in order to support third-party call control
[RFC3725].
A UAS lists multiple packages by enumerating the package name(s), This section describes how SIP UAs indicate which Info Packages they
separated by commas, as values for the Recv-Info header in the are willing to receive.
session establishment exchange. A UAS may also list multiple
packages by including multiple Recv-Info headers. The UAS may also
combine multiple Recv-Info headers with one or more packages in each
header value. If the UAS prefers to receive one package over
another, the UAS MUST list the preferred Info Package lexically
earlier in the message. That is, by listing it earlier in a list
within a given Recv-Info header or listing it in a previous Recv-Info
header in a given message. The UAS MUST NOT list a package more than
once. This order is only a hint to the UAC, as there is no
meaningful way of enforcing the use of a preferred package at the
UAC.
There is an important issue to consider when the UAS advertises 3.2. User Agent Behavior
support for multiple packages that one might interpret to be similar
or equivalent. The UAC has no method of knowing whether the UAS
would like the UAC to send a single INFO request with the preferred
package or for the UAC to send multiple INFO requests with the same
or similar information. The behavior is entirely up to the UAC and
the rules specified by the package definitions.
If a UAS does not wish to receive any Info Packages, the UAS MUST A UA which supports the Info Package mechanism MUST indicate the set
indicate this by including one and only one Recv-Info header with the of Info Packages it is willing to receive, using the Revc-Info header
value 'nil'. This enables the UAC to discern the difference between field. A UA can list multiple Info Packages in a single Recv-Info
a UAS that understands Info Packages but does not wish to receive any header field, and the UA can use multiple Recv-Info header fields.
from a legacy UAS that does not understand Info Packages. A UAC
conforming to this document can always send or receive legacy INFO
usages without packages.
Info Package capability advertisement occurs within the context of a The indication of Info Packages can take place during the session
session negotiation exchange. The Info Package capability set establishment, and during a target refresh. This includes INVITE,
received by the UAC within the last exchange is the one the UAC will UPDATE, PRACK, ACK, and their non-failure responses (101-199 and 2xx
use to chose Info Packages from. Also note that due to glare, an only). Note that the UAC is not required to indicate its set of Info
INFO request may be in flight prior to the UAC receiving an updated Packages in the initial INVITE request.
capability set removing a given Info Package. Thus, the UAS MUST be
prepared to handle an INFO request with an Info Package payload with
a newly delisted Info Package. Proper handling does include
rejecting the request with a 469. See Section 4.3 for more on this
topic.
3.2. UAC Behavior Once a UA has indicated that it is willing to to receive a specific
Info Package, and a dialog has been established, the UA MUST be
prepared to receive INFO request associated with that Info Package.
A UAC MUST NOT send INFO requests for a given INFO package until the A UA MUST NOT send INFO request associated with Info Packages until
UAC receives an "INVITE dialog usage" request or response (for it has received an indication of which Info Packages the remote UA is
session establishment or target refresh) with a Recv-Info header willing to receive.
listing the given Info Package.
At any time during an "INVITE dialog usage" request or response, if a If a UA indicates that it is willing to receive of multiple Info
UAS sends one or more Recv-Info headers, the UAC MUST replace the old Packages, which provide similar functionality, it is not possible to
set of supported Info Packages with the collection of Info Packages indicate that the UA wishes to receive only one of them. It is up to
enumerated by the current message. the application logic associated with the Info Packages, and specific
Info Package descriptions to describe application behavior in such
cases.
If the UAS does not send any Recv-Info headers in a message, then the If a UA is not willing to receive any Info Packages, during session
list of supported Info Packages does not change. establishment or later during the session, the UA MUST indicate this
by including a Recv-Info header field with a header value of 'nil'.
This enables other UAs to detect that the UA still supports the Info
Package mechanism.
A UAC MUST cease sending INFO requests for a given INFO package when Example: If a UA has previously indicated support of Info Packages
the UAC receives an "INVITE dialog usage" request or response (for foo and bar, and the UA during the session wants to indicate that it
session establishment or target refresh) that does not contain a does not want to receive any Info Packages anymore, the UA sends a
Recv-Info header listing the given Info Package. Note the UAC MUST target refresh request with a Recv-Info header field with a header
be prepared to receive a 469 response (Section 4.3) at any time, even value of 'nil'.
if the UAS advertised it could receive the Info Package. This
situation can occur if the UAC sends the INFO request at the same
time the UAS advertises it no longer supports the Info Package in
question.
If the UAC receives a Recv-Info header with the value 'nil', the UAC For backward compatibility purpose, even if a UA indicates support
MUST NOT send any INFO methods that contain Info Packages. the Info Package mechanism, it is still allowed to enable legacy
usages of INFO.
The UAS may advertise support for multiple Info Packages. If some of This document does not define a SIP option tag [RFC3261] for the Info
these packages have similar or equivalent functionality and the UAC Package mechanism. However, Info Package specifications MAY define
supports multiple such packages, the UAC SHOULD chose to send Info option-tags associated with the specific Info Package, as described
Package payload(s) from the Info Package listed lexically earlier in in Section 7.5.
the last Recv-Info advertisement the UAC received from the UAS. This
document cannot make this protocol action a must strength, as the
concept of "similar or equivalent" is highly Info Package specific.
INFO itself does not necessitate the use of Require or Proxy-Require Note that, for backward compatibility purpose, if a UA indicates
headers. There is no token defined for "Supported" headers. If support of the INFO method, it does not implicitly indicate support
necessary, clients may probe for the support of this version of INFO of the Info Package mechanism. A UA MUST use the Recv-Info header
using the OPTIONS request defined in SIP [RFC3261]. One could field to indicate support of the Info Package mechanism. Likewise,
envision a particular Info Package implementation that relied on even if a UA uses the Recv-Info header field to indicate that it
either of these headers. See Section 7 for more on this issue. support the Info Package mechanism, in addition the UA MUST still
also explicitly indicate support of the INFO method.
The presence of the Recv-Info header in a message is sufficient to 3.3. Package Versioning
indicate support for this version of INFO. The "methods" parameter
for Contact [RFC3841] is not sufficient to determine if the endpoints
support Info Packages, as the INFO method supported might be the
obsolete RFC 2976 [RFC2976] version.
For Info Packages, this draft does not provide a means of requiring The Info Package mechanism does not support package versioning.
support for a specific Info Package. If the UAS does not indicate Specific Info Package payloads MAY contain version information, which
support for an Info Package that the UAC requires, and the UAC is handled by the applications associated wit the Info Package, but
requires the use of that package, the UAC can use any supported that is outside the scope of the Info Package framework.
RFC3261 [RFC3261] method to terminate the session.
A UAC MAY send a legacy INFO [RFC2976] method at any time. Note: Even if an Info Package name contains version numbering (e.g.
foo_v2), the Info Package mechanism does not distinguish a version
number from the rest of the Info Package name.
3.3. Package Versions 3.4. REGISTER Processing
The protocol mechanism described herein does not provide for a When a UA registers, it SHALL include Recv-Info header field in the
package versioning mechanism. This is for two reasons. The first is REGISTER request, and list the Info Packages that it supports. The
that if an Info Package has a capability for forward and backward registrar MAY later use the information e.g. for forking decisions.
compatibility in the Info Package payload, then that compatibility
comes from the application level semantics of the information. This
means it is the responsibility of the application to handle such
compatibility and not the INFO framework. For example, one could use
XML versioning techniques in the payload to indicate versions of the
Info Package.
The second reason we do not have a package versioning system is not 3.5. OPTIONS Processing
all payloads have sufficient capability to carry payload versions.
In this situation, it is highly unlikely payloads will be backwards If a UA sends an OPTIONS request, or a response, the UA SHALL include
compatible. That is, what one really is defining is a new Info Recv-Info header field in the message, and list the Info Packages
Package. This is more especially so when one considers User Agents that it supports.
can advertise package support but cannot advertise package version
support. Even if we did allow for package versioning, as a parameter
to the Recv-Info header value, for example, it is lexically
equivalent to having a new Info Package.
UACs MUST NOT depend on any lexical parsing of the Info Package name A UA MUST NOT send INFO requests with Info Packages based on the
for versioning, such as "fooV1" and "fooV2" or "foo.1" and "foo.2". information the UA received in an OPTIONS request. The Info Packages
MUST be negotiated for each session.
3.4. Advertisement Example 3.6. Example
Here is an INVITE. The initiating UA advertises the following. 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 INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70 Max-Forwards: 70
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE CSeq: 314159 INVITE
Recv-Info: P, R Recv-Info: P, R
Contact: <sip:alice@pc33.example.com> Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
... ...
This means the initiating UA is willing to receive from Info Packages The UAS sends a 200 OK response back to the UAC, where the UAS
P and R. indicates that it is willing to receive Info Packages R and T.
In this next message, the target UA responds with a 200 OK:
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=a6c85cf To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE CSeq: 314159 INVITE
Contact: <sip:alice@pc33.example.com> Contact: <sip:alice@pc33.example.com>
Recv-Info: R, T Recv-Info: R, T
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: ... Content-Length: ...
... ...
This indicates the target UA is willing to receive from Info Packages Since the UAS does not support Info Package P, the UAC decides to
R and T. indicate in the ACK request that it is only willing to receive Info
Package R, which the UAS also indicated support of.
The initiating UA then confirms in an ACK, as shown.
ACK sip:ngw1@a.example.com SIP/2.0 ACK sip:ngw1@a.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
To: Bob <sip:bob@example.com>;tag=a6c85cf To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 ACK CSeq: 314163 ACK
Recv-Info: R Recv-Info: R
Content-Length: 0 Content-Length: 0
The target UA can now send from package R to the initiating UA. 4. The INFO Method
Moreover, in this example, the target UA may not send from package P, 4.1. General
as P no longer is in the initiating UA's Info Package set.
4. The INFO Method Request
4.1. INFO Requests This section describes how the UA handling of INFO requests and
responses, and message bodies carried in INFO messages. It also
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. It is important to note that can further enhance a SIP application. Annex A gives more
there are some types of application information for which using INFO details on the types of application for which the usage of INFO is
messages are inappropriate. See Appendix A for a discussion of this. seen as appropriate.
The UAC MUST include the Info-Package header field when it sends an The rules and procedures in this Section apply to implementations and
INFO request carrying an Info Package. The Info-Package header field applications which support this. Existing implementations of, and
value in an INFO request MUST contain a single Info Package token. applications using, [RFC2976], may not follow the rules in this
That Info Package token MUST match one of the Info Packages the UAS Section. Because of backward compatibility purpose such cases MUST
indicated support for during the negotiation described in Section 3. NOT be regarded as error behavior, or wrong protocol usage, but
simply part of legacy INFO usage.
The UAC MAY send an INFO in a legacy usage context. See Appendix B 4.2. INFO Request
for examples of legacy usages. In general, a legacy usage is where
there is no Info-Package header. In this case, if the UAS has never
offered a Recv-Info header or never offered a Recv-Info header with a
package of a similar function to the legacy INFO usage, the UAC MAY
send an INFO without an Info-Package header field and a body
appropriate to the said legacy usage.
A UAC MUST NOT use the INFO method outside an INVITE dialog usage. A UA MUST include a Info-Package header field, which indicates the
The INFO method has no lifetime or usage of its own, as it is Info Package contained in the request, when it sends an INFO request
inexorably linked to that of the INVITE. When the INVITE-created carrying an Info Package. An INFO request can contain only a single
session terminates, that signals the termination of the negotiated Info Package. A UA MUST NOT send INFO requests associated with Info
Info Packages. A UAS that receives an INFO message after the INVITE Packages for which the remote entity has not indicated willingness
dialog usage terminates MUST respond with a 481 Call Does Not Exist. (using the Recv-Info header filed) to receive for the session.
The session identifiers defined in RFC 3261 [RFC3261] must match A UA MAY send an INFO in a legacy usage context. In such case there
those of the provisional or final responses to the INVITE. As a is no Info Package associated with the usage, and the INFO request
result, INFO requests cannot fork. The UAC may send INFO requests does not contain an Info-Package header field. In addition, the
once the UAS has sent the Recv-Info header field value, indicating support of the legacy usage has not been negotiated using the Recv-
what the UAS supports. Info header field. See Appendix B for examples of legacy usages.
The converse is not true during initial session establishment. The The INFO method MUST NOT be used outside an INVITE dialog usage. The
initiating UA of the first INVITE MUST be prepared to receive INFO method has no lifetime or usage of its own. Supported Info
multiple INFO requests, as the first INVITE may fork. Since session Packages are negotiated on a per session basis, and the negotiation
negotiation has not completed, and we allow early INFO requests, result MUST NOT be used for other sessions. If a UA receives an INFO
multiple target UAs may respond. This initial session establishment request outside an existing dialog, the UA MUST response with a 481
phase is the only time the UAS need be prepared to receive multiple Call Does Not Exist error response.
INFO requests, as one would expect there may be messages from non-
authoritative forked dialogs prior to their termination.
The construction of the INFO request is the same as any other request Due to the possibility of forking, a UAC which during the early
within an existing INVITE-initiated session. A UAC MAY send an INFO dialog phase indicates support of one or more Info Packages (using
request on both an early and confirmed session. the Recv-Info header field) MUST be prepared to receive INFO requests
from multiple remote entities. Note that different remote entities
can indicate different sets of Info Packages which they are willing
to receive.
The INFO request MUST NOT carry a Recv-Info header. The UAC can only The construction of the INFO request is the same as any other request
negotiate Info Packages using the procedures of Section 3. within an existing INVITE dialog usage. A UA can send INFO requests
both on early and confirmed dialogs.
The signaling path for the INFO method is the signaling path The INFO request MUST NOT contain a Recv-Info header field. The UA
established as a result of the session setup. This can be direct can only indicate the Info Packages that it is willing to receive
signaling between the calling and called user agents or a signaling using the messages listed in Section 3.
path involving SIP proxy servers that were involved in the call setup
and added themselves to the Record-Route header on the initial INVITE
message.
4.2. INFO Request 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 user agents. The INFO message body SHOULD information between SIP UAs. The application data associated with an
carry this information, unless the message headers carry the Info Package SHOULD be carried as a payload in the message body of
information of interest. Note this is not an invitation to invent the INFO request, unless the information can be retrieved from a SIP
SIP headers for the purposes of application level information header field.
exchange. Rather, one could envision circumstances where existing
SIP headers already convey the information the application has
interest in.
If the Info Package defines a payload, and the package specification
indicates it is appropriate to include a payload with the request,
the UAC MUST include the payload with the MIME type specified by the
Info Package.
If the Info Package definition directs the UAC to send a request
without a payload, the UAC MUST send the INFO request without a body.
Some SIP extensions, which are orthogonal to INFO, may insert body
parts unrelated to the INFO payload. User Agents MUST conform to RFC
3261 as updated by body-handling [I-D.ietf-sip-body-handling] to
support multipart MIME handling. If there are bodies unrelated to
the Info Package, and the Info Package also has a payload, the UAC
MUST bundle these elements into a multipart MIME body. In this case,
the UAS needs a means to unambiguously identify the body part
belonging to the Info Package. To do this, the UAC MUST identify the
Info Package payload MIME body part with a Content-Disposition of
'Info-Package'.
If the payload of an Info Package is already a multipart MIME body, Info Package specifications MUST describe the application level
the UAC MUST identify the payload with a Content-Disposition of information associated with the Info Package. Message body payloads
'Info-Package' in the headers for the appropriate MIME body part. MUST have a MIME type value defined.
If there is no payload in the INFO request unrelated to the Info If a UA indicates that it is willing to receive a specific Info
Package and the payload of the Info Package is not a multipart MIME, Package, it means that the UA also supports any associated message
the UAC MUST identify the message, at the SIP header level, with a body MIME type associated with the Info Package. However, the UA
Content-Disposition of 'Info-Package'. MUST still indicate support of those MIME types also in the Accept
header filed, according to the procedures in [RFC3261].
If there is no payload for the Info Package, they UAC MAY omit the Some SIP extensions, which are orthogonal to INFO, MAY insert body
Content-Disposition header. parts unrelated to the Info Package. UAs MUST conform to [RFC3261]
as updated by body-handling [I-D.ietf-sip-body-handling] to support
multipart MIME handling.
NOTE: We could be lazy and even save 33 octets by allowing the UAC Each message body (or body part in the case of multipart MIME) MUST
to construct a non-multipart MIME payload without a Content- contain a Content-Disposition header with an 'Info-Package' header
Disposition header. However, mandating the presence makes parsing value, in order to in an easy way distinguish payloads associated
considerably easier, and it is easier to have it required now than with the Info Package from other payloads.
run into a problem later.
NOTE: One could offer that the Info-Package header is redundant, If the whole message body is associated with the Info Package, the UA
as we could have the Info Package name be a parameter for Content- MUST insert a Content-Disposition header with an 'Info-Package'
Disposition. However, there could be corner cases with legacy header value in the SIP part of the message. In that case, if
INFO usage that makes this a poor choice. multipart MIME is used, the UA does not need to insert an 'Info-
Package' header value for the individual body parts.
4.3. Responses to the INFO Request Method NOTE: To avoid corner cases with legacy INFO usage, the Info-Package
header field is used to indicate the Info Package name, rather than
to use a Content-Disposition header field parameter in order to
indicate the name.
If a UAS receives an INFO request, it MUST send a final response. A 4.4. INFO Response
UAS MUST send a 200 OK response for an INFO request with no message
body and no Info-Package header if the UAS received the INFO request
on an existing session. This protocol action supports legacy use of
INFO as a keep-alive mechanism.
If the UAS receives an INFO request with an Info-Package the UAS If a UA receives an INFO request, associated with an Info-Package
advertised with a Recv-Info in the last session state update and the that the UA has indicated willingness to receive, and the INFO
body of the INFO request is an appropriate MIME type for the Info request contains data associated with that Info-Package, the UA MUST
Package, the UAS MUST send a 200 OK response. send a 200 OK response.
If the INFO request contains a body the server does not understand If a UA receives an INFO request, associated with an Info Package
then, in the absence of Info Package associated processing rules for that the UA has not indicated willingness to receive, the UA MUST
the body, including the absence of an Info-Package header, the server send a 469 Bad INFO Package response. In the terminology of Multiple
MUST respond with a 415 Unsupported Media Type message. Dialog Usages [RFC5057], this represents a Transaction Only failure.
If the INFO request indicates an Info Package type the server does If a UA receives an INFO request for legacy usage, for which no Info-
not understand, then the server MUST respond with a 469 Bad INFO Package is associated (the INFO request does not contain an Info-
Package. In the terminology of Multiple Dialog Usages [RFC5057], Package header filed), the UA must send a 200 OK response.
this represents a Transaction Only failure.
If a server receives an INFO request with a body it understands, but If a UA receives an INFO request, which does not match any existing
the request has no Info-Package header, the UAS MAY use the body as INVITE dialog usage, the UA MUST send a 481 Call Leg/Transaction Does
it sees fit. If the UAS accepts the INFO request, the UAS MUST Not Exist response.
respond to the INFO request with a 200 OK. This enables legacy use
of INFO. If the UAS needs to enforce strict compliance with the
current INFO framework described here, the UAS MUST reject the
request with a 469.
The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message If a UA receives an INFO request, which carries a message body that
if the INFO request does not match any existing INVITE-initiated the UA does not support, and support of the message body is required
session. in the Content-Disposition header field, the UA MUST send a 415
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
support the message body.
The UAS MAY send other responses, such as Request Failure (4xx), The UAS MAY send other responses, such as Request Failure (4xx),
Server Failure (5xx) and Global Failure (6xx) as appropriate for the Server Failure (5xx) and Global Failure (6xx) as appropriate for the
request. request.
4.4. Routing Behavior 4.5. INFO Response Message Body
Unless stated otherwise, the protocol rules for the INFO request
governing the usage of tags, Route and Record-Route, retransmission
and reliability, CSeq incrementing and message formatting follow
those in RFC 3261 [RFC3261] as defined for the BYE request.
The INFO message MUST NOT change the state of the SIP session. Of
course, outside the INFO machinery specific failure responses as
documented in the SIP dialog usages document [RFC5057], may cause the
INVITE session to terminate.
4.5. Behavior of Registrars
Registrars receiving a REGISTER request that includes Recv-Info
headers MAY store such information and use it for routing purposes.
How the registrar uses this information is beyond the scope of this
document.
4.6. OPTIONS Processing
A UAC, the sender of the OPTIONS request, SHOULD include Recv-Info The response to the INFO request is normally generated by the SIP
headers, populated appropriately for the packages the UAC supports. stack before the Info Package application data has been provided to
The UAS SHOULD include its set of Recv-Info packages. These the application associated with the Info Package. Therefore, an Info
strictures are of "should" strength because local policy might Package MUST NOT define the inclusion of a message body in an INFO
restrict the advertisement of full capabilities, the UA may know the response.
best choice of equivalent packages to list from local configuration,
and so on.
The UAS and UAC MUST NOT consider the OPTIONS request to be part of a If the application that received the information needs to send some
capabilities negotiation. The OPTIONS request is purely a probe. information in the other direction, it MUST trigger a new INFO
For the UAC or UAS to renegotiate package support, they must use the request, rather than using the response of the received INFO request.
procedures described in Section 3.
4.7. Order of Delivery 4.6. Order of Delivery
The INFO method does not define mechanisms for ensuring in-order The Info Package framework relies on the CSeq header field to detect
delivery for overlapping INFO requests. That is, the UAC can send if an INFO request is received out of order.
another INFO request before receiving a transaction response from the
UAS to a prior INFO request. While the UAC will increment the CSeq
header upon the transmission of new INFO messages, the UAS cannot use
the CSeq to determine the sequence of INFO information. All a UAS
can determine is the UAC sent one INFO message after another. This
is due to the fact that there could be gaps in the INFO message CSeq
count caused by a user agent sending re-INVITES or other SIP
messages.
It is up to the individual Info Package definition to specify what If specific applications need additional mechanisms for order of
happens when there are overlapping INFO requests. However, since it delivery, those mechanisms, and related procedures, MUST be specified
is legal SIP to have overlapping requests, the application must be as part of the associated Info Package, and possible sequence numbers
able to handle the reception of overlapping requests. Overlapping etc MUST be defined as application data.
requests can occur even if the particular instance of an application
(Info Package) does not allow it, as the mechanism described here is
package-agnostic. Thus, the Info Package needs to define the
appropriate response. This is more especially so given the UAC could
send from multiple Info Packages. Some of those packages may allow
overlapping INFO requests, while others do not. In this situation,
it would be hard to tell if the non-overlapping packages were being
violated or not.
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 17, line 19 skipping to change at page 14, line 37
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 Headers 5.2. INFO Header Fields
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 - - - - - - - o* - - - - - Info-Package R - - - - - - - m* - - - - -
Recv-Info R o - - o o o o - - o - - - Recv-Info R o - - o o o o - - o - o o
Recv-Info 2xx o - - o o - o - - o - - - Recv-Info 2xx o - - 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 - - -
* Info-Package is MANDATORY for INFO messages sent using Info * The Info-Package header field is MANDATORY for INFO requests
Packages as described in this document. Info-Package is OPTIONAL for associated with Info Packages. The Info-Package header field is not
legacy (RFC2976) INFO messages. 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 5.2.1. 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. "message-header" in the SIP message grammar. Section 4 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 octet-by-octet with that of the Recv-Info header Info-Package header field octet-by-octet with that of the Recv-Info
value. That is, the Info Package name is case sensitive. Info- header field value. That is, the Info Package name is case
package-param is not part of the comparison-checking algorithm. sensitive. Info-package-param is not part of the comparison-checking
algorithm.
This document does not define values for Info-Package types. This document does not define values for Info-Package types.
Individual Info Packages define these values. Such documents MUST Individual Info Package specifications define these values. Such
register such values with IANA. These values are Specification specifications MUST register the values with IANA. These values are
Required [RFC5226]. Specification Required [RFC5226].
5.2.2. Recv-Info header 5.2.2. 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 "general-header" in the SIP [RFC3261] message grammar. Section 3
describes the Recv-Info header usage. describes the Recv-Info header field usage.
6. Legacy Uses of INFO 6. Legacy INFO Usage
Several RFC-defined and other standards-defined uses of RFC 2976 INFO A number of applications, standardized and proprietary, make use of
[RFC2976] exist and are in use, as well as numerous proprietary uses. INFO messages as defined in [RFC2976], without defined Info Packages
Appendix B describes some of these usages. By definition, the and a possibility to use SIP to indicate what INFO usages UAs are
identifying such uses has relied on either static local configuration willing to use. For backward compatibility purpose, this document
or implicit context determination based on the body Content-Type or does not deprecate such usage, and does not mandate to define Info
Content-Disposition value or some proprietary mechanism. This draft Packages for existing usages. However, any new usage of INFO SHALL
cannot forbid nor avoid such uses, since local configuration can use the Info Package mechanism defined in this specification.
always override standardized mechanisms.
To maintain backward compatibility with the extant standardized uses Since legacy INFO usages to not have associated Info Packages, it is
of INFO, a server MAY interpret an INFO request with no "Info- not possible to use the Recv-Info and Info-Package header fields for
Package" header as being of such legacy use. legacy INFO usages. That is, a UA can not use the Recv-Info header
filed to indicate for which legacy usages it is willing to receive
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.
It should be noted that such legacy use will not "break" the NOTE: For legacy INFO usages, static configuration is often used to
mechanism in this draft. For example, if a UA supports SIP-T define what specific legacy INFO usages UAs support.
[RFC3372], it does so based on static local configuration or based on
acceptance of the application/isup body. If it adds support for this
draft's Info Package negotiation mechanism, the local configuration
still applies, and the UA will send/receive INFO messages based on
SIP-T regardless of the Info Package negotiation. It will also be
able to send/receive INFO messages based on the Info Packages it
negotiated. If, at some future time, an Info Package is defined for
SIP-T, the UA can indicate such in the negotiation, and again local
configuration would supersede if need be. The UA would not lose the
ability to use SIP-T with legacy devices. Rather, it would gain the
ability to use it with devices which support this draft and with
which it did not have such local configuration set, and could avoid
failures related to unsupported bodies.
It is the hope of this draft's authors that vendors that implement An INFO request associated with an Info Package MUST contain a Info-
proprietary INFO uses submit their mechanisms as Info Package Package header field. An INFO request without an Info-Package header
extension documents, and follow the Info Package negotiation field MUST NOT contain an Info-Package header field, and the request
mechanism defined in this draft. SHALL be interpreted as being a legacy INFO usage request.
UAs are allowed to enable both legacy INFO usages and Info Package
usages as part of the same session.
7. Info Package Requirements 7. Info Package Requirements
Info Packages SHOULD NOT reiterate any of the behavior described in 7.1. General
this document, unless required for clarity or emphasis. However,
such packages MUST describe the behavior that extends or modifies the This Section provides guidance on how to define an Info Package, and
behavior described in this document. what information needs to be provided.
If an Info Package extends or modifies the behavior described in this
document, it MUST be described in the definition for that Info
Package. Info Package definitions SHOULD NOT repeat procedures
defined in this specification, unless needed for clarification or
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 document. However, Info Packages MAY strengthen or "MUST" in this specification. However, Info Packages MAY
"SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST"
the application requires it. strength if applications associated with the Info Package requires
it.
In addition to the normal sections expected in standards-track RFCs Info Package definitions SHALL address the issues defined in the
and SIP extension documents, authors of Info Packages need to address following subsections, unless an issue is not applicable for the
each of the issues detailed in the following subsections, whenever specific Info Package.
applicable.
7.1. Applicability 7.2. Applicability
This section, which MUST be present, describes why any of the other The Info Package specification MUST describe why the Info Package
established user-to-user data transfer protocols are not appropriate mechanism, rather than some other mechanism, has been chosen for the
for the given Info Package. Common reasons can be a requirement for specific use-case to transfer application information between SIP
SIP Proxies or back-to-back User Agents (B2BUAs) to see the endpoints. Common reasons can be a requirement for SIP Proxies or
application level information. Consideration in this section MUST back-to-back User Agents (B2BUAs) to see the transport application
describe what happens if one or both endpoints encrypt the payload. information, or that it is seen unfeasible to establish separate
dialogs (subscription) for transporting the information.
7.2. Info Package Name Annex A provides more information, and describes alternative
mechanisms which one should consider for solving the specific use-
case.
This section, which MUST be present, defines the token name that 7.3. Info Package Name
designates the Info Package. The name MUST conform to the token ABNF
production described in Section 8. It MUST include the information
that appears in the IANA registration of the token. For information
on registering such types, see Section 9.
7.3. Info Package Parameters The Info Package specification MUST define an Info Package name.
If the "Info-Package" header allows parameters to modify the behavior The specification MUST also define the header field value to be used
of the Info Package, this section MUST clearly define the syntax and to indicate support of this package in the Recv-Info and Info-Package
semantics of such parameters. header fields. The header field value MUST conform to the ABNF
defined in Section 8.2.
7.4. Info Package Tags The specification MUST also include the information that appears in
the IANA registration of the token. For information on registering
such types, see Section **9.
If useful for the Info Package to have SIP option tags, this is the 7.4. Info Package Parameters
place to define the tag. Note that if the Info Package defines a SIP
option tag, the Info Package must conform to the SIP Change Process
[RFC3427].
7.5. INFO Bodies The Info Package specification MAY define Info Package parameters
which can be used in the Recv-Info or Info-Package header fields,
together with the header field value representing the Info Package.
Each Info Package MUST define what type or types of bodies are The specification MUST describe the syntax and semantics of the
expected in INFO requests. Such packages MUST specify or cite parameters. It MUST be specified whether a specific parameter is
detailed specifications for the syntax and semantics associated with only applicable to the Recv-Info header, the Info-Package header, or
such a body. both.
The UAS MUST enumerate every MIME type associated with the Info Note that Info Package parameters are only applicable for the Info
Packages advertised in the UAS' Recv-Info header the UAS is willing Package(s) for which they have been explicitly defined. If used for
to receive. If a UAC sends a body that includes something not other Info Packages they MUST be discarded.
enumerated by the UAS, this is a protocol error and the UAS MUST
respond appropriately.
7.6. UAC generation of INFO requests 7.5. SIP Option Tags
Each Info Package MUST describe the process by which a UA generates The Info Package specification MAY define SIP option tags, which can
and sends an INFO request. This includes detailed information about be used as described in [RFC3261].
what events cause the UA to send an INFO request.
If the Info Package does not allow overlapping (outstanding) INFO SIP option tags MUST conform to the SIP Change Process [RFC3427].
requests, the Info Package MUST disclose this in the section
describing UA generation of INFO requests. Note the generic protocol
machinery of the INFO method has no way of enforcing such a
requirement. Section 7.7 describes this situation.
7.7. UAS processing of INFO requests 7.6. INFO Message Bodies
The Info Package MAY describe the process followed by the UA upon The Info Package specification MUST define what type of message
receipt of an INFO request. Since INFO does not change SIP state, bodies, if any, are associated with the Info Package, and MUST refer
and may not even change application state, there may be no useful to specifications where the syntax, semantics and MIME type of the
guidance required in the Info Package specification for UA message body is described.
processing.
If the info Package does not permit overlapping INFO requests, it is 7.7. Info Package Usage Restrictions
important to note the issuance of overlapping INFO requests is an
application-layer protocol failure and not an INFO method failure. The Info Package specification MUST define whether a UA is allowed to
Therefore, in the event a UAC issues overlapping INFO requests for an send overlapping (outstanding) INFO requests associated with the Info
Info Package, the UAS MUST NOT return an error response as a result Package, or whether the UA has to wait for the response for a
of the overlapping INFO request. Of course, if there are other previous INFO request associated with the same Info Package.
problems with the request that results in a failure, the UAC issues
the appropriate response code. This section of the Info Package The specification MUST define whether there SIP level restrictions in
specification MUST describe the application level response to the usage of the Info Package. For example, an Info Package may
overlapping INFO requests. Examples include a new INFO request back require support of other SIP extensions (e.g. reliable provisional
to the offending UAC indicating an application error, ignoring the responses).
overlapping request and processing it to the UAS' best effort, or
terminating the entire SIP session. The specification MUST define whether there are restrictions on
indicating support of, or using, the Info Package together with other
Info Packages.
If Info Package restrictions are violated (i.e. if overlapping INFO
requests are not allowed for an Info Package, but a UA still receives
overlapping requests), the UA MUST NOT reject such requests. Instead
the application logic associated with the Info Package MUST handle
such situations.
7.8. Rate of INFO Requests 7.8. Rate of INFO Requests
Each Info Package MUST define a requirement of MUST strength which The Info Package specification MUST a maximum rate at which INFO
defines an absolute maximum on the rate at which an Info Package of a requests associated with the specific Info Package can be generated
given type can generate INFO messages by a UA in a session. by a UA in a dialog.
If possible, a package MUST define a throttle mechanism that allows The specification MAY define Info Package parameters to be used for
UAs to further limit the rate of INFO messages. indicating or negotiating the INFO request rate. Alternatively the
rate information can be included in the application information
associated with the Info Package.
7.9. IANA Registrations 7.9. IANA Registrations
The Info Package MUST have an IANA Considerations section that The Info Package specification MUST contain an IANA Considerations
includes definitions for the Info Package Name and, if needed, section that includes definitions for the Info Package Name and, if
supported MIME types. needed, supported MIME types.
7.10. Security Considerations 7.10. Security Considerations
The INFO mechanism transports application level information. One If the application information associated with the Info Package
implication of this is INFO messages may require a higher level of requires certain level of security, the Info Package specification
protection than the underlying SIP-based session signaling. If the MUST describe the mechanisms to be used in order to provide the
application transports sensitive information, such as credit card required security.
numbers, health history, personal identifiers, and so on, the Info
Package MUST document security procedures that exceed the default
procedures presented in this document. In most circumstances, it is
not sufficient for a package to attempt to mandate TLS for the
signaling channel to secure the data carried by the INFO.
Intermediaries will have access to the payload and past the first
hop, there is no way to assure subsequent hops will not transmit the
payload in clear text. The only way to ensure secure transport at
the application level is to have the security at the application
level. The most common method of achieving this is to use end-to-end
security techniques such as S/MIME [RFC3851]. If the application
demands this level of security, the Info Package definition MUST
indicate such.
7.11. Examples Otherwise, even if no additional security than what is provided for
the underlying SIP protocol is needed, it SHALL be stated in the Info
Package specification.
We RECOMMEND Info Packages include several demonstrative message flow NOTE: In some cases, it may not be sufficient to mandate TLS in order
diagrams paired with several typical, syntactically correct, and to secure the Info Package payload, since intermediaries will have
complete messages. access to the payload and past the first hop, there is no way to
assure subsequent hops will not forwards the payload in clear text.
The best way to ensure secure transport at the application level is
to have the security at the application level. The most common
method of achieving this is to use end-to-end security techniques
such as S/MIME [RFC3851].
Documents describing Info Packages MUST clearly indicate the examples 7.11. Application Procedures
are informative and not normative, with instructions that
implementers refer to the main text of the document for exact The Info Package specification SHOULD contain a description of the
protocol details. application procedures associated with the Info Package, or
alternatively refer to application procedures defined elsewhere.
7.12. Examples
It is RECOMMENDED that Info Package specifications include
demonstrative message flow diagrams, paired with complete messages
and message descriptions.
Note that example flows are by definition informative, and MUST NOT
replace normative text
8. Syntax 8. Syntax
This section describes the syntax extensions required for the INFO 8.1. General
This Section describes the syntax extensions required for the INFO
method. The previous sections describe the semantics. Note the method. The previous sections describe the semantics. Note the
formal syntax definitions described in this document use the ABNF formal syntax definitions described in this document use the ABNF
format used in SIP [RFC3261] and contain references to elements format used in [RFC3261] and contain references to elements defined
defined therein. therein.
8.2. ABNF
INFOm = %x49.4E.46.4F ; INFO in caps INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON Info-package-list Recv-Info = "Recv-Info" HCOLON Info-package-list
Info-package-list = "nil" Info-package-list = "nil"
/ Info-package-type *( COMMA Info-package-type ) / Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( ";" Info-package-param) Info-package-type = Info-package-name *( ";" Info-package-param)
Info-package-name = token Info-package-name = token
Info-package-param = token Info-package-param = generic-param
NOTE on the Recv-Info production: if the value is "nil", there can be NOTE on the Recv-Info production: if the header field value is "nil",
one and only one Recv-Info header in the SIP message. 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. IANA Considerations
9.1. Update to Registration of SIP INFO Method 9.1. Update to Registration of SIP INFO Method
Please update the existing registration in the SIP Methods and Please update the existing registration in the SIP Methods and
Response Codes registry under the SIP Parameters registry that Response Codes registry under the SIP Parameters registry that
states: states:
Method: INFO Method: INFO
skipping to change at page 23, line 28 skipping to change at page 20, line 49
9.4. Creation of the Info Packages Registry 9.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-
sensitive tokens. Info Package Parameters are only applicable to
the Info Package for which they are defined, so the same Info
Package Parameter Names may exist for different Info Packages.
o Info Package Payload MIME Types: A list of zero or more registered 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
skipping to change at page 24, line 37 skipping to change at page 22, line 11
10.1. Simple Info Package 10.1. 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
Contact: <sip:bob@192.0.2.2>
Info-Package: foo Info-Package: foo
Content-type: application/foo Content-type: application/foo
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 10.2. Multipart INFO Example
Other SIP extensions can put payloads into an INFO method, Other SIP extensions can put payloads into an INFO method,
independent of the Info Package. In this case, the Info Package independent of the Info Package. In this case, the Info Package
payload gets put into a Multipart MIME body, with the content payload gets put into a Multipart MIME body, with the content
disposition indicating which body belongs to the Info Package. Since disposition indicating which body belongs to the Info Package. Since
there is one and only one Info Package payload in the message, we there is one and only one Info Package payload in the message, we
only need to tag which body part goes 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
Contact: <sip:bob@192.0.2.2>
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"
Content-Length: ... Content-Length: ...
--theboundary --theboundary
Content-Type: application/mumble Content-Type: application/mumble
Content-Id: abcd9999qq Content-Id: abcd9999qq
... ...
skipping to change at page 25, line 35 skipping to change at page 23, line 33
--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 11. Modifications to SIP Change Process
This document updates RFC 3427 [RFC3427] to add a process for
registering new Info Packages. The process for registering new Info
Packages follows the process outlined in Section 4.3 of RFC 3427 for
the registration of SIP Event Packages. Namely, the registration of
a new SIP Info Package requires the DISPATCH chairs to assign an
individual to perform expert review of the proposal if the work is
not a RAI work item in itself.
12. Security Considerations
By eliminating multiple uses of INFO messages without adequate By eliminating multiple uses of INFO messages without adequate
community review and by eliminating the possibility for rogue SIP community review and by eliminating the possibility for rogue SIP UAs
User Agents from confusing another User Agent by purposely sending from confusing another User Agent by purposely sending unrelated INFO
unrelated INFO messages, we expect this document's clarification of requests, we expect this document's clarification of the use of INFO
the use of INFO to improve the security of the Internet. Whilst to improve the security of the Internet. Whilst rogue UAs can still
rogue UACs can still send unrelated INFO messages, this framework send unrelated INFO requests, this framework provides mechanisms for
provides mechanisms for which the UAS and other security devices can which the UAS and other security devices can filter for approved Info
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, User Agents
will need to use end-to-end encryption, such as S/MIME, to prevent will need to use end-to-end encryption, such as S/MIME, to prevent
access to the content. This is particularly important as transport access to the content. This is particularly important as transport
of INFO is likely not to be end-to-end, but through SIP proxies and of INFO is likely not to be end-to-end, but through SIP proxies and
back-to-back user agents (B2BUA's), which the user may not trust. back-to-back user agents (B2BUA's), which the user may not trust.
The INFO mechanism transports application level information. One The INFO mechanism 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-based session signaling. In
particular, if one does not protect the SIP signaling from particular, if one does not protect the SIP signaling from
eavesdropping or authentication and repudiation attacks, for example eavesdropping or authentication and repudiation attacks, for example
by using TLS transport, then the INFO request and its contents will by using TLS transport, then the INFO request and its contents will
be vulnerable, as well. Even with SIP/TLS, any SIP hop along the be vulnerable, as well. Even with SIP/TLS, any SIP hop along the
path from UAC to UAS can view, modify, or intercept INFO requests, as path from UAC to UAS can view, modify, or intercept INFO requests, as
they can with any SIP request. This means some applications may they can with any SIP request. This means some applications may
require end-to-end encryption of the INFO payload, beyond, for require end-to-end encryption of the INFO payload, beyond, for
example, hop-by-hop protection of the SIP signaling itself. Since example, hop-by-hop protection of the SIP signaling itself. Since
the application dictates the level of security required, individual the application dictates the level of security required, individual
Info Packages have to enumerate these requirements. In any event, Info Packages have to enumerate these requirements. In any event,
the INFO Framework described by this document provides the tools for the Info Package mechanism described by this document provides the
such secure, end-to-end transport of application data. tools for such 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.
13. References 12. References
13.1. Normative References
[I-D.ietf-sip-body-handling] 12.1. Normative References
Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)",
draft-ietf-sip-body-handling-06 (work in progress),
March 2009.
[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", RFC 2119, BCP 14, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[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.
13.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
[I-D.ietf-speechsc-mrcpv2] Schooler, "SIP: Session Initiation Protocol", RFC 3261,
Shanmugham, S. and D. Burnett, "Media Resource Control June 2002.
Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-19 (work in progress),
June 2009.
[I-D.saleem-msml] [I-D.ietf-sip-body-handling]
Sharratt, G. and A. Saleem, "Media Server Markup Language Camarillo, G., "Message Body Handling in the Session
(MSML)", draft-saleem-msml-08 (work in progress), Initiation Protocol (SIP)",
February 2009. draft-ietf-sip-body-handling-06 (work in progress),
March 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 12.2. Informative References
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000. October 2000.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
RFC 3080, March 2001. "Interworking between the Session Initiation Protocol
(SIP) and QSIG", BCP 117, RFC 4497, May 2006.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Event Notification", RFC 3265, June 2002. Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
for Telephones (SIP-T): Context and Architectures", August 1980.
BCP 63, RFC 3372, September 2002.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
and B. Rosen, "Change Process for the Session Initiation RFC 4949, August 2007.
Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
and D. Gurle, "Session Initiation Protocol (SIP) Extension RFC 3080, March 2001.
for Instant Messaging", RFC 3428, December 2002.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Context for Internet Mail", RFC 3458, January 2003. Extensions (S/MIME) Version 3.1 Message Specification",
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.,
and B. Rosen, "Change Process for the Session Initiation
Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[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.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
Extensions (S/MIME) Version 3.1 Message Specification", for Telephones (SIP-T): Context and Architectures",
RFC 3851, July 2004. BCP 63, RFC 3372, September 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
Context for Internet Mail", RFC 3458, January 2003.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
Session Initiation Protocol (SIP)", RFC 4028, April 2005. Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005. Media Services with SIP", RFC 4240, December 2005.
[RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
"Interworking between the Session Initiation Protocol
(SIP) and QSIG", BCP 117, RFC 4497, May 2006.
[RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol
(SIP) Event Package for Key Press Stimulus (KPML)", (SIP) Event Package for Key Press Stimulus (KPML)",
RFC 4730, November 2006. RFC 4730, November 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[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.
skipping to change at page 29, line 24 skipping to change at page 26, line 50
Media Control", RFC 5168, March 2008. Media Control", RFC 5168, March 2008.
[W3C.REC-voicexml21-20070619] [W3C.REC-voicexml21-20070619]
Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter, Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter,
J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke, J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke,
D., Candell, E., and R. Auburn, "Voice Extensible Markup D., Candell, E., and R. Auburn, "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]
Shanmugham, S. and D. Burnett, "Media Resource Control
Protocol Version 2 (MRCPv2)",
draft-ietf-speechsc-mrcpv2-19 (work in progress),
June 2009.
[I-D.saleem-msml]
Sharratt, G. and A. Saleem, "Media Server Markup Language
(MSML)", draft-saleem-msml-08 (work in progress),
February 2009.
Appendix A. Info Package Considerations Appendix A. Info Package Considerations
This section covers several issues that one should take into A.1. General
consideration when proposing new Info Packages.
A.1. Appropriateness of Usage 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.
When designing an Info Package using the method described in this A.2. Appropriateness of Info Package Usage
document for application level information exchange, it is important
to consider: is INFO and, more importantly, is signaling within a SIP
session, an appropriate mechanism for the problem set? Is it because
it is the most reasonable and appropriate choice, or merely because
"it's easy"?
These are difficult issues to consider, especially when presented When designing an Info Package, for application level information
with real-world deadlines and implementation cost issues. However, exchange, it is important to consider: is signaling, using INFO
choosing to use INFO for inappropriate uses *will* lead to issues in requests, within a SIP session, an appropriate mechanism for the use-
the real world, not the least of which are certain types of case? Is it because it is the most reasonable and appropriate
middleboxes which will remove the device from the network if it is choice, or merely because "it's easy"? Choosing an inappropriate
found to cause damage to other SIP nodes. mechanism for a specific use-case can cause negative effects in SIP
networks where the mechanism is used.
Therefore, the following sections provide consideration guidelines A.3. Dialog Fate Sharing
and alternatives to INFO use.
A.2. Dialog Fate-Sharing As described in [RFC5057], an INFO request is always part of an
INVITE dialog usage.
INFO, by design, is a method within an INVITE dialog usage. RFC 5057 One needs to consider the fate of the dialog usage of an INFO request
[RFC5057] enumerates the problems with using dialogs for multiple is rejected. In some cases it may be acceptable that the whole
usages, and we strongly urge the reader to review RFC 5057. The most dialog useage is terminated, while in other cases is is desirable to
relevant issue is a failure of transmission or processing of an INFO maintain the dialog usage.
request may render the INVITE session terminated, depending on the
type of failure. Prior to RFC 5057, it was not clear if the INFO
usage was a separate usage or not. RFC 5057 clarifies the INFO
method is always part of the INVITE usage.
Some uses of INFO can tolerate this fate sharing of the INFO message A.4. INFO Request Rate and Volume
over the entire session. For example, in the SIP-T usage, it may be
acceptable for a call to fail, or to tear down the call, if one
cannot deliver the associated SS7 information. The same is usually
true for DTMF. However, it may not be acceptable for a call to fail
if, for example, a DTMF buffer overflows. Then again, for some
services, that may be the exact desired behavior.
A.3. Messaging Rates 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.
There is no throttling mechanism for INFO. Consider that most call Some applications, like sending of DTMF tones, can generate a burst
signaling occurs on the order of 7-10 messages per 3 minutes, of up to 20 messages per second. Other applications, like constant
although with a burst of 5-7 messages in one second during call GPS location updates, could generate a high rate of INFO requests
setup. DTMF tones occur in bursts at a rate of up to 20 messages per during the whole session.
second. This is a considerably higher rate than for call signaling.
Sending constant GPS location updates, on the other hand, would incur
an undue burden on SIP Proxies along the path.
Furthermore, SIP messages tend to be relatively small, on the order Furthermore, SIP messages tend to be relatively small, on the order
of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
exchange of bulk data beyond these limits, especially if the headers exchange of bulk data beyond these limits, especially if the headers
plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for
such traffic include MSRP [RFC4975], COMEDIA [RFC4145], or HTTP such traffic include HTTP [RFC2616], MSRP [RFC4975], or other user
[RFC2616]. plane data transport mechanisms.
A.4. Is there a better alternative?
The first 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. The SUBSCRIBE creates a new session that does
not share the fate of the related INVITE-initiated session.
Moreover, using the SUBSCRIBE model enables multiple applications to
receive state updates. These applications can be outside the media
path and potentially outside the INVITE-initiated session's proxy
path. In fact, SIUBSCRIBE/NOTIFY is your only option if you need to
exchange data outside a communications session.
SUBSCRIBE/NOTIFY messages pass through the SIP signaling
infrastructure, such as SIP Proxies and B2BUAs. Application
designers need to understand this can be a feature, as when the User
Agents are exchanging information that elements in the SIP signaling
path need to be aware of. Conversely, this can be a problem, as
messages these network elements have no interest in can put a
significant burden on those element's ability to process other
traffic. Moreover, such network elements may not be able to read
end-to-end encrypted SUBSCRIBE or NOTIFY bodies.
Implementers do need to be aware the price of having a protocol that
works in all cases, can scale, can easily load balance, and will not
mysteriously fail a session in the event of state synchronization
failure does come at a cost. Session establishment is a minimum of
two messages in addition to the INVITE session establishment. If the
SUBSCRIBE application is co-resident with the INVITE application, the
application will have to manage two SIP sessions instead of one.
Tracking the application level state dominates memory and processing
for some applications, and as such, the doubling of SIP sessions is
not an issue. However, for other applications, this may be an issue.
The MESSAGE method [RFC3428] defines one-time instant message
exchange, typically for sending MIME contents for rendering to the
user.
Another model for application level information exchange is to
establish a communication channel in the media plane. One model for
this is MRCPv2 [I-D.ietf-speechsc-mrcpv2]. Here, the INVITE-
initiated session establishes a separate reliable, connection-
oriented channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream.
One uses SIP to locate the remote endpoint, but uses a direct
connection for the UUI. One then can create whatever protocol one
wishes, whether from scratch (as in MRCPv2) or using a substrate such
as BEEP [RFC3080].
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. In addition, if there will be a lot of
information exchanged, and there is no need for the SIP routing
network to examine the information, one should use a separate media
channel.
Another model 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 RFC 4240 [RFC4240] or the encoding of a SUBMIT
target in a VoiceXML [W3C.REC-voicexml21-20070619] script.
MSRP [RFC4975] defines session-based instant messaging as well as A.5. Alternative Mechanisms
bulk file transfer and other such large-volume uses. It is part of
an INVITE-based session, similar to other media. Unlike INFO, MSRP
follows a direct media path, rather than through the network elements
composing the SIP signaling path.
A common reason people in the past used INFO for application level A.5.1. Alternative SIP signaling plane mechanisms
information exchange is the negotiation is very lightweight compared
to SUBSCRIBE/NOTIFY. This is more especially so if it is not certain
if there will be application level information exchange. The
SUBSCRIBE/NOTIFY machinery requires the user agents to exchange rich
capabilities and maintain state for additional SIP sessions.
However, this is a weak argument if there is a high likelihood of
application level information exchange. In this case, we recommend
the use of a more robust application level information exchange
protocol.
A.5. Alternatives for Common INFO Use A.5.1.1. General
What alternatives to INFO are there for UA-to-UA application session This subsection describes some alternative mechanisms for
signaling? As noted above, there are three broad classes of session transporting application information on the SIP signaling plane,
signaling available. The choice depends on the circumstances. using SIP messages.
Following is a list of situations that have used INFO in the past.
o State updates
o User stimulus
o Direct signaling channel
o Proxy-aware signaling
o Dialog probe
A.5.1. State Updates A.5.1.2. SUBSCRIBE/NOTIFY
This is the broad class of one User Agent updating another with An alternative for application level interaction is SIP Events, also
changes in state. The design goal of the SUBSCRIBE/NOTIFY [RFC3265] known as SUBSCRIBE/NOTIFY [RFC3265]. In this model, a user agent
event framework is to meet just this need. 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.5.2. User Stimulus: Touch Tones and Others 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.
This is the class of the user entering stimulus at one User Agent, The subscription mechanism can be used by SIP entities to receive
and the User Agent transporting that stimulus to the other. A key state information about SIP sessions, without requiring the entities
thing to realize is key presses on the telephone keypad is user to be part of the route set of those sessions.
stimulus. Thus, the appropriate mechanism to use here is KPML
[RFC4730].
A.5.3. Direct Signaling Channel 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.
State updates and user stimulus tend to have relatively few messages As for any other SIP signaling plane based mechanism for transporting
per session. Sometimes, User Agents need to exchange a relatively application information, the SUBSCRIBE/NOTIFY messages can put a
high number of messages. In addition, User Agents may have a need significant burden on intermediate SIP entities which are part of the
for a relatively low-latency exchange of messages. In this latter session route set, but do not have any interest in the application
case, the User Agent may not be able to tolerate the latency information transported between the end users.
introduced by intermediate proxies. Likewise, the intermediate
proxies may have no interest in processing all of that data.
In this case, establishing a separate, direct control channel, as in A.5.1.3. MESSAGE
MSRP [RFC4975] or MRCPv2 [I-D.ietf-speechsc-mrcpv2] is appropriate.
In addition, not every situation requires a SIP solution. Some The MESSAGE method [RFC3428] defines one-time instant message
signaling is really just one-shot to third-party endpoints. That exchange, typically for sending MIME contents for rendering to the
situation may better be handled using an appropriate protocol, such user.
as HTTP [RFC2616].
A.5.4. Proxy-Aware Signaling A.5.2. Media Plane Mechanisms
Sometimes, one does want proxies to be in the signaling path for UA- A.5.2.1. General
to-UA application signaling. In this case, the use of a SIP request
is appropriate. To date, there are no mechanisms for completely
disambiguating INFO requests. For example, one could create a
registry of INFO packages. The definition of the package would
define the contexts for the various MIME Content-Types, as well as
the context of the request itself. However, a package can have
multiple content types. Moreover, having the context, or package
identifier, at the SIP level precludes bundling multiple contexts
responding in the same INFO request. For example, a User Agent might
want to bundle two different responses in a multipart/mixed MIME body
type.
Because there is no difference in either the protocol machinery or In SIP, media plane channels associated with SIP sessions are
registration process due to these factors, we will not create an INFO established using SIP signaling, but the data exchanged on the media
framework. If one needs a SIP User Agent-to-SIP User Agent plane channel does not traverse SIP signaling intermediates, so if
application session signaling transport protocol that touches all there will be a lot of information exchanged, and there is no need
Record-Route proxies in a path, one MUST create a new SIP method as for the SIP signaling intermediates routing to examine the
described in Section 27.4 of RFC 3261 [RFC3261]. information, it is recommended to use a media plane mechanism, rather
than a SIP signaling based.
A.5.5. Dialog Probe 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.
Some implementations in the wild use INFO to probe if an INVITE- A.5.2.2. MRCPv2
initiated session is alive. While this works, it is NOT RECOMMENDED.
In particular, RFC 4028 [RFC4028] describes how to ensure an INVITE-
initiated session is alive.
A.5.6. Malicious Indicator 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.
Take the case of Malicious Indicator. This is where a subscriber A.5.2.3. MRSP
receives a call, realizes it is a malicious call (threatening, SPIT,
etc.). They then press the SPIT button (or press *xx), which tells
their service provider to mark the UAC as a bad actor. One might be
tempted to think that INFO would be a great option for this service.
It follows the return path of the INVITE, and so the INFO will hit
the caller's inbound proxy, which it can learn the caller is
(statistically) a bad actor. That way the inbound proxy can do stuff
like notify law enforcement, add a vote to "this is a SPIT source,"
or other useful action.
However, consider a few issues. First, since INFO lives exclusively MSRP [RFC4975] defines session-based instant messaging as well as
within an established session, there is no way to assert this message bulk file transfer and other such large-volume uses.
after the call completes. Second, this mechanism relies on an active
service provider topology. If there is no proxy in the chain that
will eat the INFO, the caller will see the "this is a bad guy"
message, which may have consequences in the real world. Third, there
is no a'priori way for the UAS to know whether it can issue the INFO.
The caller certainly will not advertise, "please tell me if I am bad,
particularly I know in advance that I *am* a bad actor."
One approach is for the service provider's proxy to SUBSCRIBE for the A.5.3. Non-SIP related mechanisms
SPIT event at the UAS. At this point, life is good, interoperable,
and works across networks. This enables events after the session is
torn down, as presumably the SPIT event will refer not to, "this
session," which does not exist, but to "that session identifier,"
which exists (and is theoretically unique) forever.
Another approach that saves considerably on the overhead of Another alternative is to use a totally externally signaled channel,
subscriptions would be for the service provider to insert a HTTP URI such as HTTP [RFC2616]. In this model, the user agent knows about a
in the initial INVITE, noting it is for reporting malicious behavior. rendezvous point to direct HTTP requests to for the transfer of
When the subscriber presses the SPIT button, an HTTP POST gets information. Examples include encoding of a prompt to retrieve in
executed, delivering the call information to the service provider. the SIP Request URI in [RFC4240] or the encoding of a SUBMIT target
The service provider can encode basic call information in the HTTP in a VoiceXML [W3C.REC-voicexml21-20070619] script.
URI and can instruct the device to send whatever arbitrary data is
necessary in the POST. This method has the added benefit of being
entirely outside the real-time SIP proxy network.
Appendix B. Legacy INFO Usages Appendix B. Legacy INFO Usages
We do not intend this section to be a comprehensive catalog of INFO We do not intend this section to be a comprehensive catalog of INFO
usages. However, it should give the reader a flavor for current INFO usages. However, it should give the reader a flavor for current INFO
usages. usages.
B.1. ISUP B.1. ISUP
SIP-T uses Content-Type to identify ISUP protocol elements in an INFO SIP-T uses Content-Type to identify ISUP protocol elements in an INFO
skipping to change at page 36, line 44 skipping to change at page 31, line 44
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
o Moved the example in section 3 into its own sub-section, and used o Moved the example in section 3 into its own sub-section, and used
full SIP headers full SIP header fields
o Clarified forking behavior o Clarified forking behavior
o Clarified language around when to send a body o Clarified language around when to send a body
o Added 469 error response, instead of reusing 489 o Added 469 error response, instead of reusing 489
o Clarified overlapping INFO method handling o Clarified overlapping INFO method handling
o Fixed table 1 to follow 3261, not 2543 o Fixed table 1 to follow 3261, not 2543
o Added REFER to the INFO Headers table o Added REFER to the INFO Headers table
o replaced token-nodot with token for Info-Package values o replaced token-nodot with token for Info-Package header field
values
o Clarified end-to-end security considerations o Clarified end-to-end security considerations
o Info Package parameters are semi-colon delimited, not dot o Info Package parameters are semi-colon delimited, not dot
delimited delimited
Changes from -02 Changes from -02
o Applicability statement explicitly says we're backwards compatible o Applicability statement explicitly says we're backwards compatible
o Explicitly state we work like UPDATE (both early and confirmed o Explicitly state we work like UPDATE (both early and confirmed
dialogs) dialogs)
o Agreed text for IANA Considerations package registry o Agreed text for IANA Considerations package registry
Changes from -01 Changes from -01
o One and only one Info Package per INFO o One and only one Info Package per INFO
o Removed Send-Info header, greatly simplifying negotiation o Removed Send-Info header field, greatly simplifying negotiation
o Multiple body part identification through Content-Disposition: o Multiple body part identification through Content-Disposition:
Info-Package Info-Package
o Note that forking INVITEs may result in multiple INFO's coming o Note that forking INVITEs may result in multiple INFOs coming back
back to INVITE originator to INVITE originator
o Describe how a UAS can enforce strict adherence to this document o Describe how a UAS can enforce strict adherence to this document
o Remove CANCEL INFO faux pas o Remove CANCEL INFO faux pas
o Better explained overlapping INFO issues and resolutions o Better explained overlapping INFO issues and resolutions
o Token names are now really case sensitive o Token names are now really case sensitive
o Moved Info Package Considerations to an Appendix o Moved Info Package Considerations to an Appendix
o Introduced stronger, yet more open, IANA registration process o Introduced stronger, yet more open, IANA registration process
o Took a few more paragraphs from INFO Litmus to cover all bases. o Took a few more paragraphs from INFO Litmus to cover all bases.
o Added RFC 5168 to legacy usages o Added RFC 5168 to legacy usages
Changes from -00 Changes from -00
skipping to change at page 37, line 45 skipping to change at page 32, line 46
o Enabled sending of legacy INFO messages. Receiving legacy INFO o Enabled sending of legacy INFO messages. Receiving legacy INFO
messages was already here. messages was already here.
o Negotiation is not Offer/Answer, it is Offer/Offer. o Negotiation is not Offer/Answer, it is Offer/Offer.
o Created the explicit "nil" Info Package to indicate no info o Created the explicit "nil" Info Package to indicate no info
package. package.
o Fixed CANCEL impacting future transactions. o Fixed CANCEL impacting future transactions.
o Added Registrar behavior. o Added Registrar behavior.
o Added OPTIONS processing. o Added OPTIONS processing.
o Clarified overlapping INFO method processing. o Clarified overlapping INFO method processing.
o Described multiple INFO bodies in a single INFO method. o Described multiple INFO bodies in a single INFO method.
o Took out Info-Package as a header for responses to the INFO o Took out Info-Package as a header field for responses to the INFO
method. method.
o Expanded on risks of using INFO and filled-in more on the o Expanded on risks of using INFO and filled-in more on the
alternatives alternatives
o Moved definitions of INFO into the body of the text and cleaned up o Moved definitions of INFO into the body of the text and cleaned up
IANA Considerations section IANA Considerations section
o Added legacy usages descriptions o Added legacy usages descriptions
Authors' Addresses Authors' Addresses
Eric W. Burger Eric W. Burger
NeuStar, Inc. NeuStar, Inc.
46000 Center Oak Plaza 46000 Center Oak Plaza
Sterling, VA 20166-6579 Sterling, VA 20166-6579
USA USA
 End of changes. 190 change blocks. 
952 lines changed or deleted 685 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/