| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2009.
This document defines the new INFO method and a mechanism for defining, negotiating and exchanging Info Packages that use the INFO method. Applications which need to exchange session-related information within a SIP INVITE-created dialog use these INFO requests. This draft addresses issues and open items from RFC 2976, and replaces it.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
2.
Terminology
3.
Applicability
4.
Info Package Negotiation
4.1.
Info Package Negotiation Overview
4.2.
UAC Behavior
4.3.
UAS Behavior
5.
The INFO Method Request
5.1.
INFO Requests
5.2.
Responses to the INFO Request Method
5.3.
Behavior of SIP User Agents
5.4.
Behavior of Registrars
5.5.
OPTIONS Processing
5.6.
INFO Message Bodies
6.
Legacy Uses of INFO
7.
Info Packages
7.1.
Appropriateness of Usage
7.1.1.
Dialog Fate-Sharing
7.1.2.
Messaging Rates and Volume
7.1.3.
Is there a better alternative?
7.2.
Info Package Responsibilities
7.2.1.
Applicability
7.2.2.
Info Package Name
7.2.3.
Info Package Parameters
7.2.4.
INFO Bodies
7.2.5.
UA generation of INFO requests
7.2.6.
UA processing of INFO requests
7.2.7.
Rate of notifications
7.2.8.
Examples
8.
Syntax
9.
IANA Considerations
9.1.
New Method
9.2.
INFO Method
9.3.
New Headers
9.3.1.
Info-Package header
9.3.2.
Send-Info header
9.3.3.
Recv-Info header
10.
Example
11.
Security Considerations
12.
References
12.1.
Normative References
12.2.
Informative References
Appendix A.
Acknowledgements
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The SIP protocol (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] defines session control messages used to setup and tear down a SIP controlled session. In addition, a SIP User Agent (UA) can use the re-INVITE and UPDATE methods during a session to change the characteristics of the session. Most often, this is to change the properties of media flows related to the session or to update the SIP session timer (Donovan, S. and J. Rosenberg, “Session Timers in the Session Initiation Protocol (SIP),” April 2005.) [RFC4028]. The purpose of the INFO message (Donovan, S., “The SIP INFO Method,” October 2000.) [RFC2976], on the other hand, is to carry application level information along the SIP signaling path.
While INFO use has been widely adopted for specific application use cases, such as ISUP and DTMF exchange, RFC 2976 (Donovan, S., “The SIP INFO Method,” October 2000.) [RFC2976] neither defined a negotiation mechanism nor a means by which to explicitly indicate the type of application information contained in the INFO message. This led to problems associated with static configuration. In addition, the industry realized there was a potential for interoperability problems due to undefined content syntax and semantics. This draft addresses these deficiencies, provides a framework for explicit negotiation of capabilities and content context using "Info Packages".
The INFO method does not provide any context for the information which it carries. While it may sometimes be clear what the content is based on the Content-Type, this is only true where there is only one contextual usage of the content-type. For example, if the Content-Type is "image/jpeg", the MIME-attached content is a JPEG image. However, there is no indication what the purpose of the image is. The image could be a caller-id picture, a contact icon, a photo for sharing, and so on. The sender does not know which JPEG to give the receiver if the receiver supports a JPEG content type, and the receiver does not know which JPEG the client is sending if the receiver supports receiving more than one JPEG content type. Thus there needs to be a well-defined and documented statement of what the information sent is for. This situation is identical to the context issue in Internet Mail (Burger, E., Candell, E., Eliot, C., and G. Klyne, “Message Context for Internet Mail,” January 2003.) [RFC3458]. RFC 3458 goes into this and other issues in detail.
Event Packages (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] perform the role of disambiguating the context of a message for Subscription-based events. This document provides a similar framework for INVITE-based information exchange. The mechanism defined in this draft has no relationship to the SUBSCRIBE and NOTIFY methods. The mechanism defined here neither creates a separate subscription dialog nor a subscription usage within an existing dialog. Instead, it uses the INVITE method and its responses to indicate and negotiate supported Info Packages, and the INFO method to convey the Info Packages. This mechanism is not appropriate for IANA-registered Subscribe Event (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] package types. Info Package definitions and registrations indicate support for this mechanism when one registers them with IANA.
Each UA enumerates which Info Packages it can send and receive. If the far end indicates it can receive a package offered by the near end, the near end can send INFO methods containing the payload for that package. Likewise, if the far end indicates it can send a package the near end offers it can receive, the far end can send INFO methods containing the payload for that package. The Recv-Info header indicates which packages a UA is willing to receive and the Send-Info header indicates which packages a UA is willing to send. The Package-Info header indicates which package a particular INFO method request belongs to. The presence of empty Send-Info and Recv-Info headers indicates the UA conforms with this document, but does not wish to send or receive Info Packages. This enables other UAs that conform with this document to detect legacy UAs, as the legacy UA will not include Send-Info or Recv-Info headers in their SIP requests. Section 4 (Info Package Negotiation) describes the negotiation in detail.
This document does not describe any specific Info Package type extensions. One must extend this protocol by other documents, herein referred to as "Info Packages." Section 7.1 (Appropriateness of Usage) describes guidelines for creating these extensions.
The INFO method does not change the state of SIP calls or the parameters of the sessions SIP initiates. It merely sends optional application layer information, generally related to the session.
Applications need to be aware that application level information transported by the INFO method constitutes mid-dialog signaling information. These messages traverse the post-session-setup SIP signaling path. This is the path taken by SIP re-INVITEs, BYEs, and other SIP requests that within an individual dialog. SIP proxy servers will receive, and potentially act on, mid-dialog 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 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.
This draft replaces the SIP INFO document (Donovan, S., “The SIP INFO Method,” October 2000.) [RFC2976].
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119]. The terminology in this document conforms to the Internet Security Glossary (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.) [RFC4949].
| TOC |
This draft proposes replacing the [RFC2976] SIP INFO method document (Donovan, S., “The SIP INFO Method,” October 2000.) [RFC2976] to 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.
RFC EDITOR NOTE: Please replace "This draft proposes replacing" with "This draft replaces" in the final edition.
| TOC |
In this section, "UAC" is the User Agent Client from the perspective of the INVITE method. That is, it is the User Agent (UA) that sends the initial INVITE method request. This may be somewhat confusing if the User Agent Server (UAS) from the perspective of the INVITE method sends an INFO method request.
| TOC |
Info Package negotiation is similar, but not the same, as negotiating SDP (Rosenberg, J. and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” June 2002.) [RFC3264]. It is similar, in that the UAC may offer a set of Send-Info and Recv-Info packages in the initial INVITE, the UAS offers its set of Send-Info and Recv-Info pacakges in provisional 1xx and final 2xx responses, and the UAC may offer a final set of Send-Info and Recv-Info packages in the ACK. Likewise, the UAC may chose not to offer any packages in the initial INVITE, and negotiate packages from the UAS' subsequent responses and the ACK, in order to support third-party call control (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [RFC3725].
Info Package negotiation MAY occur any time the UAs negotiate session parameters. Examples are session establishment, as described in the above paragraph; re-INVITE; and UPDATE (Rosenberg, J., “The Session Initiation Protocol (SIP) UPDATE Method,” October 2002.) [RFC3311], to name a few. The general rule is before a UA may begin sending INFO methods with a given Info Package, the UAC must have first indicated it wants to send the Info Package by listing it in a Send-Info header in the most recent dialog negotiation and the UAS must have positively indicated it is willing to receive the Info Package by listing it in a Recv-Info header in the most recent dialog negotiation.
A UA MAY list multiple packages by enumerating the package name(s), separated by commas, as values for the Send-Info and Recv-Info headers in the session establishment. A UA MAY list multiple packages by including multiple Send-Info and Recv-Info headers. A UA MAY combine these two methods. We do NOT RECOMMEND listing a package multiple times in a given session establishment message, but there is no harm in doing so.
If a UA does not wish to receive any Info Packages, the UA MUST indicate this by including an empty Recv-Info header. Likewise, if a UA does not wish to send any Info Packages, the UA MUST indicate this by including an empty Send-Info header. This enables the other UA to discern the difference between the first UA understanding Info Packages but not wishing to receive any from a UA that does not understand Info Packages.
The UAC and UAS MUST NOT send an INFO message until the UAC and UAS negotiate which Info Packages they support, in which direction. The dialog state satisfies this requirement once both the UAC and UAS have exchanged Send-Info and Recv-Info headers in the appropriate session negotiation messages (INVITE, 1xx, 2xx, ACK, etc.). Once both UAs have exchanged Send-Info and Recv-Info headers, the UAC MUST NOT send an INFO message carrying a given Info-Package type if the UAC did not advertise the package in its Send-Info and the UAS did not advertise the package in its Recv-Info. This is the DeMorgan's Theorem of saying the UAC may only send an INFO message for the given package if (1) the UAC lists the package in its Send-Info and (2) the UAS lists the package in its Recv-Info.
Once a UAC advertises it is willing to receive a package, it MUST be ready to receive INFO methods carrying that package type. This is because the UAS MAY send such INFO requests at the same time as the UAS sends its confirming Send-Info header, and the request may arrive out of order. This also enables early exchange of INFO methods.
[EDITOR'S NOTE: is not waiting for a dialog to fully establish a problem? Personally, I doubt it. Even the corner cases, like forking, do not bother me.]
It is important to note that if a UAS does not list a package in its Send-Info package list, the UAS MUST NOT send Info Packages from that package, even if the UAC listed the package in its Recv-Info package list. The UAS will have to renegotiate the session parameters to do this. For example, if a UAC offers
(preamble)
Send-Info: P, Q Recv-Info: P, R
(postamble)
and the UAS responds
(preamble)
Send-Info: P, T Recv-Info: Q, R
(postamble)
the UAC MAY start to send INFO messages with type Q, the intersection of {P, Q} and {Q, R}. Likewise, the UAS MAY send INFO messages with type P, the intersection of {P, T} and {P, R}.
Such Info Package capability negotiation MUST occur within the context of a single session negotiation exchange. Moreover, the last capability set received within the exchange is the one the receiver applies against its advertised capability set. For example, if in an INVITE, the UAC offers
(preamble)
Send-Info: P, Q Recv-Info: P, R
(postamble)
and the UAS in a 200 OK responds
(preamble)
Send-Info: P, T Recv-Info: Q, R
(postamble)
and the UAC then confirms in an ACK with
(preamble)
Send-Info: P, Q Recv-Info: T
(postamble)
the UAS can now send from package T. Moreover, in this example, the UAS may not send form package P, as P no longer is in the UAC's Info Package set.
The limitation on requiring the negotiation to occur within the context of a session negotiation exchange means that if the UAC issues a re-INVITE (after the above ACK) with
(preamble)
Recv-Info: P, R, T
(postamble)
the UAS MUST NOT send any package P INFO methods until the UAS re-offers P in its Send-Info header in its 200 OK response.
INFO does not necessitate the use of "Require" or "Proxy-Require" headers. There is no token defined for "Supported" headers. If necessary, clients may probe for the support of this version of INFO using the OPTIONS request defined in SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261].
The presence of the "Send-Info" or "Recv-Info" header in a message is sufficient to indicate support for this version of INFO. Note the "methods" parameter for Contact (Rosenberg, J., Schulzrinne, H., and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” August 2004.) [RFC3841] is not sufficient to determine if the endpoints support Info Packages, as the INFO method supported might be the obsolete RFC 2976 (Donovan, S., “The SIP INFO Method,” October 2000.) [RFC2976] version.
For Info Packages, this draft does not provide a means of requiring support for a specific Info Package. If the far-end UA does not indicate support for an Info Package that the local server requires, the server MAY terminate the session with a CANCEL or BYE request.
Since the protocol handshake generates some set of Send-Info and Recv-Info packages, including the empty set, the absence of Send-Info and Recv-Info headers at the end of session negotiation indicates a legacy UA that does not understand the Info Package mechanism described in this document. However, be aware a conforming UAC may chose to not include the Send-Info and Recv-Info headers in its initial INVITE message to a UAS, as described in the next section.
| TOC |
NOTE: In this section, UAC refers to the initiator of an INVITE-initiated dialog and not necessarily the UAC receiving an INFO method request.
A UAC MAY indicate one or more Info Packages it wishes to support sending during the INVITE dialog by including their IANA-registered names in the Send-Info header field value in the INVITE request. Including an empty Send-Info header field indicates the UAC does not wish to send any Info Packages at this time. The UAC MAY modify the Send-Info list at any time during session negotiation.
The UAC MAY indicate one or more Info Packages it wishes to support receiving during the INVITE-created dialog by including their Info Package names in the Recv-Info header field in the INVITE request. Not including the Recv-Info header field in the INVITE does not necessarily mean the UAC will not accept Info Packages during the dialog. The UAC MAY include a Recv-Info header in a later phase of the session negotiation.
Once a UAC indicates support for receiving a given Info Package, the UAC MUST be ready to accept INFO methods carrying that package type.
When the UAC receives a Recv-Info header field in any provisional 1xx or 2xx response, it is an indication the UAS supports receiving the Info Packages indicated in the header field value. The UAC ignores any Info Packages in the Recv-Info header field value from the UAS the UAC did not offer in a Send-Info header field. This situation does not constitute a protocol failure, as the UAC is not going to send such Info Packages. In other words such mismatches do not fail the negotiation. However, if the UAS indicates support for receiving an Info Package the UAC did not indicate it will send, the UAC MUST NOT send such Info Packages.
When the UAC receives a Send-Info header field in any provisional 1xx or 2xx final response, it is an indication the UAS supports sending Info Package(s) named in the header field value. Note the UAC will only receive Info Package(s) the UAC indicates it is willing to receive in the Recv-Info header field.
Once the UAC and UAS establish an early dialog through a 1xx provisional response with To-tags, and the UAC has received a Recv-Info header field values from the UAS in the response, the UAC MAY send any Info Packages supported by the UAS in an INFO message. The 2xx final response updates the state of the supported Info Packages, such that the 2xx contains the full and final list of Send-Info and Recv-Info Info Packages. If the 2xx contains an empty Send-Info header field, the UAS is indicating it will not send any, and if it contains an empty Recv-Info header field, the UAS will not accept any, regardless of what a previous 1xx response might have indicated. At this point negotiation is complete.
Similar rules apply for late Send-Info / Recv-Info negotiation, such as an empty INVITE, followed by an offer in the 200 OK and the response in the ACK.
| TOC |
When a UAS receives an INVITE request, it checks for Send-Info and Recv-Info header fields.
For each Info Package name in the received Send-Info header field value, if the UAS wishes to accept receiving such Info Packages from the UAC, the UAS MUST copy the type token name(s) of the acceptable Info Packages into a Recv-Info header field value in any and all subsequent provisional 1xx and final 2xx responses.
Likewise, for each Info Package name listed in the received Recv-Info header field value, if the UAS wishes to send such Info Packages to the UAC, the UAC MUST copy the name(s) of those Info Packages it wishes to generate into a Send-Info header field value in subsequent provisional 1xx and final 2xx responses. The UAS MAY decide not to indicate any Info Packages in early 1xx responses, but add them or change them in subsequent 1xx and final 2xx responses. If the UAS no longer wishes to support an Info Package after the provisional response, the UAS MUST indicate such by removing it from the Send-Info or Recv-Info header field values in subsequent provisional and the 2xx final response, and if no Info Packages are remaining then by including the appropriate header field(s) with empty value(s).
[EDITOR'S NOTE: The original text said: "The UAS MUST NOT send any INFO messages with Info Packages until it has received an acknowledgement, such as PRACK for a provisional response or an ACK for a final response, that the UAC has received the SIP response sent by the UAS, indicating the UAC received the Send-Info header field values from the UAS. This assures the UAC can perform any necessary logic it needs in order to receive the Info Package and can associate the INFO message and associated Info Package with the proper dialog." Is it OK to ditch this text? In theory, it is "good" to have full handshaking and allow for prep work on the part of the UAC. In practice can anyone think of situations where this will make a difference? The state machine is much simpler without it.]
Unlike the NOTIFY method, the INFO method cannot establish a dialog.
| TOC |
In this section, "UAC" is the User Agent Client from the perspective of the INFO method. That is, it is the User Agent (UA) that sends the INFO method request. This may be somewhat confusing if the UA that is sending an INFO method is the User Agent Server (UAS) that received the initial SIP INVITE. In this case, the UAS from the INVITE perspective is the UAC from the INFO perspective. Be aware this section is strict on calling the UAC the UA that is sending the INFO method request.
| TOC |
The INFO method communicates application level information along the signaling path for the call. The INFO method does not change the state of sessions initiated by SIP. Any proposal to have INFO change the state of a SIP call is an architectural error and one MUST NOT allow it. The INFO method provides additional, application level information that can further enhance a SIP application. It is important to note there are some types of application information for which using INFO messages are inappropriate. See Section 7.1 (Appropriateness of Usage) for a discussion of this.
This draft creates a new, mandatory header field for INFO requests, the "Info-Package" header field. The "Info-Package" header field value in an INFO request contains a single Info Package token. The token in the "Info-Package" header field value MUST match one of the Info Package tokens received in the "Recv-Info" header field value in the received INVITE for the UAS or response for the UAC. In other words, one can only send what the other end is willing to receive.
One can only use the INFO method within an INVITE-generated dialog (early or full) and usage. The INFO method has no lifetime or usage of its own, as it is inexorably linked to that of the INVITE. When the INVITE-created dialog terminates, that signals the termination of the negotiated Info Packages. A UA that receives an INFO message after the other UA sends a BYE or CANCEL MUST respond with a 481 Call Does Not Exist.
The dialog identifiers defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] must match those of the provisional or final responses to the INVITE. As a result, INFO requests do not fork. Either UA may send INFO requests, once each UA has exchanged the Send-Info/Recv-Info header field value indications of what the far-end supports.
The signaling path for the INFO method is the signaling path established as a result of the call setup. This can be direct signaling between the calling and called user agents or a signaling 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.
| TOC |
If a UAS receives an INFO request it MUST send a final response. A 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 dialog. This protocol action supports legacy use of INFO as a keep-alive mechanism.
If the UAS receives an INFO request with a Package-Info the UAC advertised with a Send-Info in the last dialog state update and the UAS advertised with a Recv-Info and the body of the INFO request is an appropriate MIME type for the Info Package, the UAS MUST send a 200 OK repsonse.
If the INFO request contains a body that the server does not understand then, in the absence of Info Package associated processing rules for the body, including the absence of an Info-Package header, the server MUST respond with a 415 Unsupported Media Type message.
If the INFO request indicates an Info Package type that the server does not understand, then the server MUST respond with a 489 Bad Event. The server then MUST terminate the INVITE dialog, as this represents a protocol failure.
[EDITOR'S NOTE: I chose 489 as 405 implies a media mis-match and 501 implies INFO is not supported. This protocol failure is identical to a NOTIFY with an event package the UAS did not subscribe to. We could create a new response code if you have problems with "Bad Event" implying there is some link between INFO and NOTIFY. However, I would offer what we are doing is refining 489 to mean, "received some package in some context that I do not understand," where today the possible contexts are INFO and NOTIFY. Work for you?]
If a server receives an INFO request with a body it understands, but it has no Info-Package header, the UAS MAY render the body. Note the semantics of "rendering" is up to the Info Package definition. The UAS MUST respond to the INFO request with a 200 OK. This enables legacy use of INFO.
The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message if the INFO request does not match any existing dialog.
The UAS MAY send other responses, such as Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx) as appropriate for the INFO Request.
[EDITOR'S NOTE: Need to check 2976 to make sure we cover all the bases here, as we are obsoleting that document and this becomes the sole, normative reference.]
| TOC |
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 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] as defined for the BYE request.
A UAC MAY CANCEL an INFO request. A UAS receiving a CANCEL for an INFO request SHOULD respond to the INFO with a "487 Request Cancelled" response unless the UAC has already sent a final response. The UAS then MUST ignore future INFO requests.
The INFO message MUST NOT change the state of the SIP dialog. The only exception to this rule is for specific failure responses as documented in RFC 5057 (Sparks, R., “Multiple Dialog Usages in the Session Initiation Protocol,” November 2007.) [RFC5057], which may cause the INVITE dialog to terminate.
| TOC |
[EDITOR'S NOTE: TBD]
| TOC |
[EDITOR'S NOTE: TBD]
| TOC |
The INFO request MAY contain a message body. If the request contains a message body, the Info Package type extension document MUST specify the syntax and semantics of the INFO body.
The purpose of the INFO message is to carry application level information between SIP user agents. The INFO message body SHOULD carry this information, unless the message headers carry the information of interest.
In addition, the INFO method does not define mechanisms for ensuring in-order delivery. 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. 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.
| TOC |
Several RFC-defined and other standards-defined uses of RFC 2976 INFO (Donovan, S., “The SIP INFO Method,” October 2000.) [RFC2976] exist and are in use, as well as numerous proprietary uses. By definition, such uses have relied on either static local configuration or implicit context determination based on the body Content-Type or Content-Disposition value, or some proprietary mechanism. This draft cannot forbid nor avoid such uses, since local configuration can always override standardized mechanisms.
To maintain backward compatibility with the extant standardized uses of INFO, a server MAY interpret an INFO request with no "Info-Package" header as being of such legacy use.
It should be noted that such legacy use will not "break" the mechanism in this draft. For example, if a UA supports SIP-T (Vemuri, A. and J. Peterson, “Session Initiation Protocol for Telephones (SIP-T): Context and Architectures,” September 2002.) [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 proprietary INFO uses submit their mechanisms as Info Package extension documents, and follow the Info Package negotiation mechanism defined in this draft.
| TOC |
This section covers several issues which one should take into consideration when propsing new Info Packages.
| TOC |
When designing an Info Package using the method described in this document for application level information exchange, it is important to consider: is INFO and, more importantly, is signaling within a SIP dialog, 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 with real-world deadlines and implementation cost issues. However, choosing to use INFO for inappropriate uses *will* lead to issues in the real world, not the least of which are certain types of middleboxes which will remove the device from the network if it is found to cause damage to other SIP nodes.
Therefore, the following sections provide consideration guidelines and alternatives to INFO use.
| TOC |
INFO, by design, is a method within an INVITE dialog usage. RFC 5057 (Sparks, R., “Multiple Dialog Usages in the Session Initiation Protocol,” November 2007.) [RFC5057] enumerates the problems with using dialogs for multiple usages, and we strongly urge the reader to review RFC 5057. The most relevant issue is a failure of transmission or processing of an INFO request may render the INVITE dialog 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 over the entire dialog. 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.
| TOC |
There is no throttling mechanism for INFO. Consider that most call signaling occurs on the order of 7-10 messages per 3 minutes, although with a burst of 5-7 messages in one second during call setup. DTMF tones occur in bursts at a rate of up to 20 messages per 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 of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange of bulk data beyond these limits, especially if the headers plus body exceed the UDP MTU (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768]. Appropriate mechanisms for such traffic include MSRP (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975], COMEDIA (Yon, D. and G. Camarillo, “TCP-Based Media Transport in the Session Description Protocol (SDP),” September 2005.) [RFC4145], or HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616].
| TOC |
The design goal of the SUBSCRIBE/NOTIFY (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) [RFC3265] event framework is to meet the general need of periodic state notifications/updates. Subscribes have their own dialog or usage, and thus can outlive an INVITE one, but they can also follow the path of the INVITE-based dialog.
The MESSAGE method (Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging,” December 2002.) [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user.
MSRP (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.) [RFC4975] defines session-based instant messaging as well as 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.
| TOC |
Info Packages SHOULD NOT reiterate any of the behavior described in this document, unless required for clarity or emphasis. However, such packages MUST describe the behavior that extends or modifies the behavior described in this document.
Info Packages MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this document. However, Info Packages MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if the application requires it.
In addition to the normal sections expected in standards-track RFCs and SIP extension documents, authors of Info Packages need to address each of the issues detailed in the following subsections, whenever applicable.
| TOC |
This section, which MUST be present, describes why any of the other established user-to-user data transfer protocols are not appropriate for the given Info Package. Common reasons can be a requirement for SIP Proxies or back-to-back User Agents (B2BUAs) seeing the application level information transfer. Consideration in this section MUST describe what happens if one or both endpoints encrypt the payload.
| TOC |
This section, which MUST be present, defines the token name that designates the Info Package. It MUST include the information that appears in the IANA registration of the token. For information on registering such types, see Section 9 (IANA Considerations).
| TOC |
If the "Info-Package" header allows parameters to modify the behavior of the Info Package, this section MUST clearly define the syntax and semantics of such parameters.
| TOC |
Each Info Package MUST define what type or types of bodies are expected in INFO requests. Such packages MUST specify or cite detailed specifications for the syntax and semantics associated with such a body.
Info Packages also MUST define a default MIME type if the "Accept" header fails to define any MIME types in the INVITE request.
| TOC |
Each Info Package MUST describe the process by which a UA generates and sends an INFO request. This includes detailed information about what events cause the UA to send an INFO request.
This section MAY describe the behavior used to process the subsequent response.
| TOC |
The Info Package MAY describe the process followed by the UA upon receipt of an INFO request. Since INFO does not change SIP state, and may not even change application state, there may be no useful guidance required in the Info Package specification for UA processing.
| TOC |
Each Info Package MUST define a requirement of SHOULD or MUST strength which defines an absolute maximum on the rate at which an Info Package can generate INFO messages by a UA in a dialog.
Each package MAY further define a throttle mechanism that allows UAs to further limit the rate of INFO messages.
| TOC |
We RECOMMEND Info Packages include several demonstrative message flow diagrams paired with several typical, syntactically correct, and complete messages.
Documents describing Info Packages MUST clearly indicate the examples are informative and not normative, with instructions that implementers refer to the main text of the document for exact protocol details.
| TOC |
This section describes the syntax extensions required for user-to-user data exchange in SIP. The previous sections describe the semantics. Note the formal syntax definitions described in this document use the ABNF format used in SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] and contain references to elements defined therein.
The Augmented BNF definitions for the various new and modified syntax elements follow. The notation is as used in SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261]. See SIP for any elements not defined in this section.
(preamble)
INFOm = %x49.4E.46.4F ; INFO in caps
extension-method = INFOm / token
Info-Package = "Info-Package" HCOLON Info-package-type
Send-Info = "Send-Info" HCOLON Info-package-type
*( COMMA Info-package-type )
Recv-Info = "Send-Info" HCOLON Info-package-type
*( COMMA Info-package-type )
Info-package-type = Info-package-name *( "." Info-package-param)
Info-package-name = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" ) ;rfc3265
Info-package-param = generic-param ;this doesn't work due to dot!(postamble)
| TOC |
[EDITOR'S NOTE: We will fix this section in the next revision of the document.]
| TOC |
This document describes one new SIP method: INFO. This document replaces the definition and registrations found in [RFC2976] (Donovan, S., “The SIP INFO Method,” October 2000.).
This table expands on tables 2 and 3 in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
Table 1: Summary of Header Fields
Header Where INFO ------ ----- ---- Accept R o Accept-Encoding R o Accept-Language R o Allow 200 - Allow 405 o Authorization R o Call-ID gc m Contact R o Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Encoding e o Content-Length e o Content-Type e * CSeq gc m Date g o Encryption g o Expires g o From gc m Hide R o Max-Forwards R o Organization g o Priority R o Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Require R o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Response-Key R o Record-Route R o Record-Route 2xx o Route R o Server r o Subject R o Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o
(postamble)
| TOC |
This document adds "INFO" to the definition of the element "Method" in the SIP message grammar.
Like all SIP method names, the INFO method name is case sensitive. The INFO method transmits application level information within an INVITE-based dialog.
| TOC |
This table expands on tables 2 and 3 in [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
(preamble)
Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT -------------------------------------------------------------------- Info-Package R - - - - - - - m - - - - Info-Package r - - - - - - - o - - - - Send-Info R - - - o o o - - - - - - Send-Info 2xx - - - o o - - - - - - - Send-Info 1xx - - - o o - - - - - - - Send-Info r - - - - o - - - - - - - Recv-Info R - - - o o o - - - - - - Recv-Info 2xx - - - o o - - - - - - - Recv-Info 1xx - - - o o - - - - - - - Recv-Info r - - - - o - - - - - - -
(postamble)
| TOC |
This document adds Info-Package to the definition of the element "message-header" in the SIP message grammar.
For the purposes of matching Info Package types indicated in Send-Info or Recv-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 "Info-Package" header byte-by-byte with that of the same in the "Send-Info" or "Recv-Info" header values. The Info-package-param is not part of the comparison checking algorithm.
This document does not define values for Info-Package types. Individual Info Packages define these values. Such documents MUST register such values with IANA. That is, they are "Specification Required."
There MUST be exactly one Info Package type listed per Info-Package header. Multiple Info-Packages per INFO message are disallowed.
[EDITOR NOTE: Really? Why not multiple Info-Packages, in a multipart/mime? Well, I thought of one: it is hard to disambiguate. For example, take an INFO message with an Info-Package: key_image, caller_picture. I then have a multipart/mime with, you guessed it, an image/jpeg and an image/jpeg. I would offer we do allow this and require the MIME parse order of the body match the order of the Info-Package enumerations; if you have too many packages or body parts or they do not align, you barf. However, I timed out on this and thus we will have to wait for the next version for me to flesh this out. If we do do this, then we'll reference RFC 3261 as updated by draft-ietf-sip-body-handling to require multipart MIME handling.]
| TOC |
This document adds Send-Info to the definition of the element "general-header" in the SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] message grammar. Section 4 (Info Package Negotiation) describes the Send-Info header usage.
| TOC |
This document adds Recv-Info to the definition of the element "general-header" in the SIP (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] message grammar. Section 4 (Info Package Negotiation) describes the Recv-Info header usage.
| TOC |
In the following example, Alice initiates a call to Bob. Alice can support sending or receiving "foo" Info Packages, and sending "bar" Info Packages.
Alice generates the following: (note: much has been left out for simplicity)
(preamble)
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice <sip:alice@example.net>;tag=1234567 To: Bob <sip:bob@example.com> Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: <sip:alice@192.0.2.1> Send-Info: foo, bar Recv-Info: foo
(postamble)
Bob checks the header field values. He can support sending but not receiving "foo", and sending but not receiving "bar". Since Bob does not support receiving anything Alice can send, the response lists an empty Recv-Info header.
(preamble)
SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice <sip:alice@example.net>;tag=1234567 To: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Send-Info: foo Recv-Info:
(postamble)
Since he sent the Send-Info header field value in the 180, and still wishes to support it, Bob also sends it in the 200 response.
(preamble)
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice <sip:alice@example.net>;tag=1234567 To: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: <sip:bob@192.0.2.2> Send-Info: foo Recv-Info:
(postamble)
Alice can send an Info Package as soon as she received the 180, but in this example she would not have been able to do so since Bob didn't say he could receive any Info Packages in his 180 response. Bob must wait to receive the ACK before sending any "foo" packages (ACK not shown), at which point he sends the following:
(preamble)
INFO sip:alice@192.0.2.1 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice <sip:alice@example.net>;tag=1234567 From: Bob <sip:bob@example.com>;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 2 INFO Contact: <sip:bob@192.0.2.2> Info-Package: foo
(postamble)
| TOC |
By eliminating multiple uses of INFO messages without adequate community review and by eliminating the possibility for rogue SIP User Agents from confusing another User Agent by purposely sending unrelated INFO messages, we expect the INFO use clarification to improve the security of the Internet.
There are no specific security issues for this mechanism, beyond those already applicable to SIP-based session signaling. In particular, if one does not protect the SIP signaling from eavesdropping or authentication and repudiation attacks, for example 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 path from UAC to UAS can view, modify, or intercept INFO requests, as they can with any SIP request.
One interesting property of Info Package use is one can reuse the same digest-challenge mechanism used for INVITE-based authentication for the INFO request. For example one could use a quality-of-protection (qop) value of authentication with integrity (auth-int), to challenge the request and its body, and prevent intermediate devices from modifying the body. However this assumes the device 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 credentials.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate 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 (TXT). |
| TOC |
| TOC |
We are standing on the shoulders of giants. Jonathan Rosenberg did the original "INFO Considered Harmful" Internet Draft on 26 December 2002, which influenced the work group and this document. Likewise, Dean Willis influenced the text from his Internet Draft, "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" of 15 January 2003. My, we have been working on this for a long time!
This and other related drafts have elicited well over 450 messages on the SIP list. People who have argued with its thesis, supported its thesis, added to the examples, or argued with the examples, include the following individuals:
Adam Roach, Bram Verburg, Brian Stucker, Chris Boulton, Cullen Jennings, Dale Worley, Dean Willis, Frank Miller, Gonzalo Camarillo, Gordon Beith, Henry Sinnreich, James Jackson, James Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, Robert Sparks, Roland Jesske, Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and Xavier Marjou.
John Elwell and Francois Audet helped with QSIG references. In addition, Francois Audet provided actual text for the revised abstract.
The work group version of this document benefited from the close readings and comments from John Elwell, Paul Kyzivat, Dean Willis, Francois Audet, Dale Worley, and Andrew Allen. However, any errors are still our own.
| TOC |
| Eric W. Burger | |
| This Space Available to the Most Interesting Bidder | |
| USA | |
| Email: | eburger@standardstrack.com |
| URI: | http://www.standardstrack.com |
| Hadriel Kaplan | |
| Acme Packet | |
| 71 Third Ave. | |
| Burlington, MA 01803 | |
| USA | |
| Phone: | |
| Fax: | |
| Email: | hkaplan@acmepacket.com |
| URI: | |
| Christer Holmberg | |
| Ericsson | |
| Hirsalantie 11 | |
| Jorvas, 02420 | |
| Finland | |
| Phone: | |
| Fax: | |
| Email: | christer.holmberg@ericsson.com |
| URI: |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.