SIP Working Group H. Kaplan Internet Draft Acme Packet Intended status: Standards Track C. Holmberg Expires: August 25, 2008 Ericsson E. Burger BEA Systems, Inc. February 25, 2008 The SIP INFO Method and Info Package Framework draft-kaplan-sip-info-events-01 Status of this Memo 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/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 August 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Kaplan, et al. Expires August 25, 2007 [Page 1] The SIP INFO Method and Info Packages February 2008 Abstract This document defines the INFO method and a mechanism for defining, negotiating and exchanging Info Packages in it. INFO requests are used within SIP INVITE-created dialogs, for applications which need to exchange session-related information inside the INVITE-created dialog. This draft addresses issues and open items from RFC 2976, and replaces it. Table of Contents 1. Introduction..........................................3 1.1. Background............................................4 2. Terminology...........................................4 3. Applicability.........................................5 4. The INFO Method Request...............................5 4.1. Responses to the INFO Request Method..................6 4.2. Message Body Inclusion................................6 4.3. Behavior of SIP User Agents...........................7 4.4. Behavior of SIP Proxy and Redirect Servers............7 4.4.1 Proxy Server..........................................7 4.4.2 Forking Proxy Server..................................7 4.4.3 Redirection Server....................................7 4.5. INFO Message Bodies...................................7 5. Info Package Negotiation..............................8 5.1. Info Package Negotiation Overview.....................8 5.2. UAC Behavior..........................................8 5.3. UAS Behavior..........................................9 6. General..............................................10 6.1. Re-Invites and usages and forks, oh my!..............10 6.2. Detecting support for INFO and Info Packages.........11 7. Legacy Uses of INFO..................................11 8. Info Packages........................................12 8.1. Appropriateness of Usage.............................12 8.1.1 Dialog Fate-Sharing..................................12 8.1.2 Messaging Rates and Volume...........................13 8.1.3 Proxy-path Signaling.................................13 8.1.4 Is there a better alternative?.......................13 8.2. Info Package Responsibilities........................14 8.2.1 Info Package Name....................................14 8.2.2 Info Package Parameters..............................14 8.2.3 INFO Bodies..........................................14 8.2.4 UA generation of INFO requests.......................15 8.2.5 UA processing of INFO requests.......................15 8.2.6 Rate of notifications................................15 8.2.7 Examples.............................................15 9. Syntax...............................................15 9.1. New Method...........................................16 9.1.1 INFO Method..........................................17 Kaplan, et al. Expires - August 2008 [Page 2] The SIP INFO Method and Info Packages February 2008 9.2. New Headers..........................................17 9.2.1 "Info-Package" header................................17 9.2.2 "Send-Info" header...................................18 9.2.3 "Recv-Info" header...................................18 9.3. Augmented BNF Definitions............................18 10. Example Exchange.....................................19 11. Security Considerations..............................20 12. IANA Considerations..................................20 13. Acknowledgements.....................................20 14. References...........................................21 14.1. Normative References.................................21 14.2. Informative References...............................21 Authors' Addresses..........................................22 Full Copyright Statement....................................23 Intellectual Property Statement.............................23 Acknowledgment..............................................23 1. Introduction The SIP protocol described in [RFC3261] defines session control messages used during the setup and tear down stages of a SIP controlled session. In addition, the SIP re-INVITE and UPDATE can be used during a session to change the characteristics of the session. This is generally to change the properties of media flows related to the session or to update the SIP session timer per [RFC4028]. The purpose of the INFO message, on the other hand, is to carry application level information along the SIP signaling path. The INFO method is not used to 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. It is necessary that the mid-dialog signaling information traverse the post session setup SIP signaling path. This is the path taken by SIP re-INVITEs, BYEs and other SIP requests that are tied to an individual dialog. This allows SIP proxy servers to receive, and potentially act on, the mid-dialog signaling information. The SIP INFO method was defined in [RFC2976] to convey such session related control information inside an INVITE-created dialog. This draft is meant to replace [RFC2976] SIP INFO. While INFO use has been widely adopted for specific application use cases, such as ISUP and DTMF exchange, the original RFC did not define a negotiation mechanism nor a means by which to explicitly indicate the type of application information contained in the INFO. This led to problems associated with static configuration, and potential interoperability problems due to undefined content syntax and semantics. This draft aims at addressing those deficiencies, to Kaplan, et al. Expires - August 2008 [Page 3] The SIP INFO Method and Info Packages February 2008 provide a framework for explicit negotiation of capabilities and content context using "Info Packages". This document does not describe any specific Info Package type extensions which may be used directly; it must be extended by other documents (herein referred to as "Info Packages"). In object- oriented design terminology, it may be thought of as an abstract base class which must be derived into an instantiated class by further extensions. Guidelines for creating these extensions are described in section 8. 1.1. Background The INFO method as defined in [RFC2976] did 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, such is only true while only one contextual usage of the content-type is ever employed. For example, if the Content-Type were "image/jpeg", it would be clear that the MIME-attached content was a JPEG image, but not what its purpose was. It could be being sent as a caller-id picture, or as a contact-icon, or whatever. The sender is not sure which JPEG to give the receiver if it supports a JPEG content-type, and the receiver does not know which JPEG is being sent if it supports receiving more than one. Thus there needs to be a well- defined and documented statement of what the information sent is for. Event Packages, as defined in [RFC3265] perform that role for Subscription-based events, whereas this document provides a similar framework for INVITE-based information exchange. However this document does NOT use the Events Package semantics of Subscriptions, and is wholly unrelated to [RFC3265]. Unlike [RFC3265], the mechanism defined in this draft is not based on the usage of the SUBSCRIBE and NOTIFY methods, and does not create a separate subscription dialog or 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 package types, and support for this mechanism should be explicitly indicated in future Info Package definitions and registrations. 2. Terminology 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. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". Kaplan, et al. Expires - August 2008 [Page 4] The SIP INFO Method and Info Packages February 2008 3. Applicability This draft proposes replacing the [RFC2976] SIP INFO method document to include explicit negotiation of supported Info Packages in the INVITE transaction, and indication of the indicated Info Package using a new header field in the INFO request. 4. The INFO Method Request The INFO method is used for communicating mid-session signaling information along the signaling path for the call. The INFO method is not used to change the state of SIP calls, nor does it change the state of sessions initiated by SIP. Rather, it provides additional optional information which can further enhance the application using SIP. There are some types of application information for which using INFO messages is inappropriate - a discussion of this can be found in section 8.1. 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 will contain a single Info Package token name which is being signaled by the INFO request. 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. The INFO method can only be used within an INVITE-generated dialog (early or full) and usage. It has no lifetime or usage of its own, as it is inexorably linked to that of the INVITE. When the INVITE- created dialog is terminated, the lifetime of the negotiated Info Packages is also terminated. Any INFO message received after a BYE or CANCEL has been sent MUST be responded to with a 481 Call Does Not Exist. The dialog identifiers defined in [RFC3261] must match those of the provisional or final responses to the INVITE, and as a result INFO requests do not fork. INFO requests may be sent in either direction, once the UAC or UAS has received the Send-Info/Recv-Info header field value indications of what the far-end supports. For the UAS, it MUST receive the ACK for the INVITE's 200-ok, or the PRACK for a provisional response, before sending an INFO request. In other words it must know the far-end UAC has received its indication of what Info Packages it is willing to send before it sends them. The signaling path for the INFO method is the signaling path established as a result of the call setup. This can be either Kaplan, et al. Expires - August 2008 [Page 5] The SIP INFO Method and Info Packages February 2008 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. The mid-session information can be communicated in either an INFO message header or as part of an INFO message body. The definition of the message body and/or message headers used to carry the mid- session information is defined by the specific named Info Package definition. The semantics are derived from the specific Info Package extension documented for usage in INFO. 4.1. Responses to the INFO Request Method If a server receives an INFO request it MUST send a final response. A 200 OK response MUST be sent by a UAS for an INFO request with no message body if the INFO request was successfully received for an existing call. Beyond that, no additional operations are required. A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a UAS if the INFO request does not match any existing call leg. If a server receives an INFO request with a body it understands, but it has no knowledge of Info Package associated processing rules for the body, the body MAY be rendered and displayed to the user. The INFO is responded to with a 200 OK. 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, 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 [TBD: 405 or 501 seem most appropriate, and do not terminate the INVITE dialog]. Bodies which imply a change in the SIP call state or the sessions initiated by SIP MUST NOT be sent in an INFO message. Other request failure (4xx), Server Failure (5xx) and Global Failure (6xx) responses MAY be sent for the INFO Request. 4.2. Message Body Inclusion The INFO request MAY contain a message body, which MUST be specified by the Info Package type extension document. INFO bodies are expected to provide additional details about the nature of the Kaplan, et al. Expires - August 2008 [Page 6] The SIP INFO Method and Info Packages February 2008 information being exchanged and the resultant resource state, if any. 4.3. Behavior of SIP User Agents 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 [RFC3261] as defined for the BYE request. An INFO request MAY be cancelled. A UAS receiving a CANCEL for an INFO request SHOULD respond to the INFO with a "487 Request Cancelled" response if a final response has not been sent to the INFO and then behave as if the request were never received. However, the INFO message MUST NOT change the state of the SIP call, or the INVITE sessions initiated by SIP. The only exception to this rule is for specific failure responses as documented in [RFC5057], which may cause the INVITE dialog to terminate. 4.4. Behavior of SIP Proxy and Redirect Servers [Do we still need to handle 3 different types of Proxies this way? This is from RFC2976] 4.4.1 Proxy Server Unless stated otherwise, the protocol rules for the INFO request at a proxy are identical to those for a BYE request as specified in [RFC3261]. 4.4.2 Forking Proxy Server Unless stated otherwise, the protocol rules for the INFO request at a proxy are identical to those for a BYE request as specified in [RFC3261]. 4.4.3 Redirection Server Unless stated otherwise, the protocol rules for the INFO request at a proxy are identical to those for a BYE request as specified in [RFC3261]. 4.5. INFO Message Bodies The purpose of the INFO message is to carry mid-session information between SIP user agents. This information will generally be carried Kaplan, et al. Expires - August 2008 [Page 7] The SIP INFO Method and Info Packages February 2008 in message bodies, although it can be carried in headers in the INFO message. The definition of the message bodies or any new headers created for the INFO method MUST be defined by separately documented Info Package extensions. Info Packages MUST define semantics associated with the body of their INFO requests. In addition, the INFO method does not define additional mechanisms for ensuring in-order delivery. While the CSeq header will be incremented upon the transmission of new INFO messages, this should not be used 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. 5. Info Package Negotiation 5.1. Info Package Negotiation Overview The general concept is that the UAC generating an INVITE request includes the Info Package types it supports sending and receiving, in two new header fields: Send-Info and Recv-Info. If the UAS supports this mechanism, it responds with the Info Packages it wishes to actually receive and send in the same named header fields (in reverse), in the provisional and final responses. When either side has indication of what the far-end supports, it may send the information defined by the Info Packages in an INFO request, following the same INVITE-created dialog and usage. The INFO request indicates the specific Info Package it is associated with, using an "Info-Package" header field with the Info Package type name, and any associated MIME-attached body defined for that Info Package. The UAC and UAS MUST negotiate which Info Packages are supported and will be used in which direction, before sending an INFO message for any specific Info Package. Negotiation always starts with the UAC indicating which Info Packages it supports and wishes to send or receive, using the two new header fields "Send-Info" and "Recv- Info", in the INVITE request. The UAS always indicates which Info Packages, of those offered by the UAC, it wishes to accept for sending and receiving to/from the UAC in its responses. 5.2. UAC Behavior A UAC supporting this draft MAY indicate one or more Info Packages it wishes to support sending during the Invite dialog, by including their RFC-defined names in the "Send-Info" header field value in the INVITE request. Not including the Send-Info header field in the Kaplan, et al. Expires - August 2008 [Page 8] The SIP INFO Method and Info Packages February 2008 INVITE means the UAC does not have an intention, and MUST NOT, send any Info Packages during the dialog. 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 means the UAC will not accept Info Packages during the dialog. When the UAC receives a Recv-Info header field in any provisional 1xx or 2xx response, it is an indication from the far-end UAS that it (the UAS) supports receiving the Info Packages indicated in the header field value. Any indicated Info Packages in the Recv-Info header field value from the UAS which were not offered by the UAC in a Send-Info header field value MUST be ignored, and MUST NOT constitute a protocol failure. In other words such mismatches do not fail the negotiation - the extraneous Info Packages are merely ignored. When the UAC receives a Send-Info header field in any provisional 1xx or 2xx final response, it is an indication from the far-end UAS that it (the UAS) supports sending Info Package(s) named in the header field value. Any indicated Send-Info header field values from the UAS which were not offered by the UAC in a Recv-Info header field value MUST be ignored, and MUST NOT constitute a protocol failure. Once an early dialog is established, 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 does not contain a Send-Info header field, the UAS is indicating it will not send any, and if it does not contain a 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 considered complete. 5.3. UAS Behavior When a UAS receives an INVITE request, it checks for a Send-Info and Recv-Info header fields. One or both may exist. For each Info Package name in the received Send-Info header field value, the UAS decides if it wishes to accept receiving such Info Packages from the UAC. If so, it MUST copy the type token name(s) of those acceptable Info Packages into a Recv-Info header field value in any, and all subsequent, provisional 1xx and final 2xx responses. Kaplan, et al. Expires - August 2008 [Page 9] The SIP INFO Method and Info Packages February 2008 For each Info Package name listed in the received Recv-Info header field value, the UAS decides if it wishes to send such Info Packages to the UAC. If so, it MUST copy the name(s) of those Info Packages it wishes to generate into a Send-Info header field value in any, and all subsequent, provisional 1xx and final 2xx responses. Note that "any, and all subsequent," means that the UAS MAY decide not to indicate any Info Packages in early 1xx responses; but once it indicates such in a 1xx, it MUST continue to do so in subsequent responses including the final 2xx response in order to keep the Info Package support state the same. If the UAS no longer wishes to support them after the provisional response, it MUST indicate such by removing them from the Send-Info or Recv-Info header field values in any subsequent provisional and the 2xx final response, and if no Info Packages are remaining then by not including the appropriate header field(s). The UAS MUST NOT send any INFO messages with Info Packages until it has received an acknowledgement (e.g. PRACK for a provisional response, or an ACK for a final response it sent) that the UAC has received the SIP response sent by the UAS, indicating that the UAC has received the Send-Info header field values from the UAS. This assures the UAC can perform any necessary logic it needs to in order to receive the Info Package, and can associate the INFO message and associated Info Package with the proper dialog. NOTE: Unlike the NOTIFY method, the INFO method CAN NOT be used to establish a dialog. 6. General 6.1. Re-Invites and usages and forks, oh my! A Re-INVITE or UPDATE request MUST NOT contain any Send-Info or Recv-Info header fields, and such header fields MUST be ignored on reception. The Info Package negotiation is performed during the initial INVITE transaction, and there is no re-negotiation. [Is that ok? Is there a need to have re-negotiation? (is there a use case?) It sure makes it simple not to have things change in the middle of a session. Adam points out 3PCC needs it - TBD by SIP-WG] There is no separate "usage" for the INFO request, as defined by [RFC5057]. The INFO is related to but not integral to the Invite usage, such that some failure responses to an INFO request do not affect the INVITE usage whatsoever, as described in [RFC5057]. Other failures may terminate the usage or dialog completely. The lifetime of Info Packages is exactly the same as that of the INVITE. Kaplan, et al. Expires - August 2008 [Page 10] The SIP INFO Method and Info Packages February 2008 If an INVITE usage fails or is terminated, the Info Package-based state no longer exists, and an INFO request MUST NOT be sent. The original INVITE request may be forked along the path, resulting in multiple 1xx provisional responses, each with a separate set of send/receive Info Packages supported. It is typically up to local- policy to determine how to handle such situations, however it should be clear that an INFO request does not itself fork, since it uses the dialog identifiers and follows [RFC3261] and thus follows the path to a specific fork. 6.2. Detecting support for INFO and Info Packages INFO does not necessitate the use of "Require" or "Proxy-Require" headers; similarly, there is no token defined for "Supported" headers. If necessary, clients may probe for the support of INFO using the OPTIONS request defined in SIP [RFC3261]. The presence of the "Send-Info" or "Recv-Info" header in a message is sufficient to indicate support for INFO. The "methods" parameter for Contact may also be used to specifically announce support for INFO messages when registering. (See [CALLER-PREFS] for details on the "methods" parameter). 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. [TBD: do we need a Require option-tag or similar mechanism?] 7. Legacy Uses of INFO Several RFC-defined and other standards-defined uses of [RFC2976] INFO 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 standardized uses of INFO, a server MAY interpret an INFO request with no "Info-Package" header as being of such legacy use. [TBD: what response if not supported?] It should be noted that such legacy use will not "break" the mechanism in this draft. For example, if a UA supports [SIP-T] use Kaplan, et al. Expires - August 2008 [Page 11] The SIP INFO Method and Info Packages February 2008 previously, it did 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 would still apply, 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 - 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 which implement proprietary INFO uses submit their mechanisms as Info Package extension documents, and follow the Info Package negotiation mechanism defined in this draft. 8. Info Packages This section covers several issues which should be taken into consideration when new Info Packages are proposed. 8.1. Appropriateness of Usage When designing an Info Package using the method described in this document for 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 try to provide consideration guidelines and alternatives to INFO use. 8.1.1 Dialog Fate-Sharing INFO, by design, is a method within an INVITE dialog usage. [RFC5057] enumerates the problems with using dialogs for multiple usages, and we strongly urge the reader to review RFC 5057. The Kaplan, et al. Expires - August 2008 [Page 12] The SIP INFO Method and Info Packages February 2008 most relevant issue is a failure of transmission or processing of an INFO may render the INVITE dialog terminated, depending on the type of failure. Prior to [RFC5057] it was underspecified if the INFO usage was a separate usage or not. However, 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; likewise 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. 8.1.2 Messaging Rates and Volume 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. 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, but at least it is infrequent in nature during the duration of a call. 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, which is more appropriate for [MSRP], [COMEDIA], or HTTP. 8.1.3 Proxy-path Signaling Using INFO means all Record-Routing proxies, and B2BUA's, in the path between the UA's will receive the INFO messages. For some applications, such as DTMF, this may be desirable, while for others this may have no benefit whatsoever. If there is no benefit, then it is imposing unnecessary processing burden on the proxies. In addition, User Agents may have a need for a relatively low-latency exchange of messages. In this latter case, the User Agent may not be able to tolerate the latency introduced by intermediate proxies. Likewise, the intermediate proxies may have no interest in processing all of that data. 8.1.4 Is there a better alternative? The design goal of the SUBSCRIBE/NOTIFY [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 Kaplan, et al. Expires - August 2008 [Page 13] The SIP INFO Method and Info Packages February 2008 INVITE one, but they can also follow the path of the INVITE-based dialog. The MESSAGE method in [RFC3428] was defined for one-time instant message exchange, typically for sending MIME contents which should be rendered to the user. [MSRP] was created for 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, it follows a more direct media-plan path, rather than the SIP signaling one. 8.2. Info Package Responsibilities Info packages are not required to reiterate any of the behavior described in this document, although they may choose to do so for clarity or emphasis. In general, though, such packages are expected to describe only the behavior that extends or modifies the behavior described in this document. Note that any behavior designated with "SHOULD" or "MUST" in this document is not allowed to be weakened by extension documents; however, such documents may elect to strengthen "SHOULD" requirements to "MUST" strength if required by their application. 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. 8.2.1 Info Package Name This section, which MUST be present, defines the token name to be used to designate the Info Package. It MUST include the information which appears in the IANA registration of the token. For information on registering such types, see section 12. 8.2.2 Info Package Parameters If parameters are to be used on the "Info-Package" header to modify the behavior of the Info Package, the syntax and semantics of such parameters MUST be clearly defined. 8.2.3 INFO Bodies Each Info Package MUST define what type or types of bodies are expected in INFO requests. Such packages MUST specify or cite Kaplan, et al. Expires - August 2008 [Page 14] The SIP INFO Method and Info Packages February 2008 detailed specifications for the syntax and semantics associated with such a body. Info Packages also MUST define which MIME type is to be assumed if none are specified in the "Accept" header of the INVITE request. 8.2.4 UA generation of INFO requests This section of an Info Package describes the process by which a UA generates and sends an INFO request. This includes detailed information about what events cause INFO to be sent. Such a section is required. This section may optionally describe the behavior used to process the subsequent response. 8.2.5 UA processing of INFO requests This section of an Info Package describes the process followed by the UA upon receipt of an INFO request. 8.2.6 Rate of notifications Each Info Package is expected to define a requirement (SHOULD or MUST strength) which defines an absolute maximum on the rate at which INFO messages are allowed to be generated for the package by a UA in a dialog. Each package MAY further define a throttle mechanism which allows UAs to further limit the rate of INFO messages. 8.2.7 Examples Info Packages SHOULD include several demonstrative message flow diagrams paired with several typical, syntactically correct, and complete messages. It is RECOMMENDED that documents describing Info Packages clearly indicate that such examples are informative and not normative, with instructions that implementers refer to the main text of the document for exact protocol details. 9. Syntax This section describes the syntax extensions required for event notification in SIP. Semantics are described in previous sections. Note that the formal syntax definitions described in this document are expressed in the ABNF format used in SIP [RFC3261], and contain references to elements defined therein. Kaplan, et al. Expires - August 2008 [Page 15] The SIP INFO Method and Info Packages February 2008 9.1. New Method This document describes one new SIP method: INFO. This table expands on tables 2 and 3 in SIP [RFC3261]. 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 Kaplan, et al. Expires - August 2008 [Page 16] The SIP INFO Method and Info Packages February 2008 Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o Table 1 Summary of header fields 9.1.1 INFO Method "INFO" is added 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 is used to transmit session-related information within an INVITE-based dialog. 9.2. New Headers This table expands on tables 2 and 3 in SIP [RFC3261]. [Should the new header fields be optional for OPTIONS and REGISTER? TBD by SIP-WG] 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 - - - - - - Send-Info 2xx - - - o o - - - - - - - Send-Info 1xx - - - o o - - - - - - - Send-Info r - - - - o - - - - - - - Recv-Info R - - - o - o - - - - - - Recv-Info 2xx - - - o o - - - - - - - Recv-Info 1xx - - - o o - - - - - - - Recv-Info r - - - - o - - - - - - - 9.2.1 "Info-Package" header Info-Package is added 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, the Info-package-name portion of the Info-package-type portion of the "Info-Package" header is compared byte-by-byte with that of the Kaplan, et al. Expires - August 2008 [Page 17] The SIP INFO Method and Info Packages February 2008 same in the "Send-Info" or "Recv-Info" header values. In other words, the Info-package-param is not used for comparison checking. This document does not define values for Info-Package-types. These values will be defined by individual Info Packages, and MUST be registered with the IANA. There MUST be exactly one Info Package type listed per Info-Package header. Multiple Info-Packages per INFO message are disallowed. 9.2.2 "Send-Info" header Send-Info is added to the definition of the element "general-header" in the SIP [RFC3261] message grammar. Its usage is described in section 5. 9.2.3 "Recv-Info" header Recv-Info is added to the definition of the element "general-header" in the SIP [RFC3261] message grammar. Its usage is described in section 5. 9.3. Augmented BNF Definitions The Augmented BNF definitions for the various new and modified syntax elements follows. The notation is as used in SIP [RFC3261], and any elements not defined in this section are as defined in SIP and the documents to which it refers. 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! Kaplan, et al. Expires - August 2008 [Page 18] The SIP INFO Method and Info Packages February 2008 10. Example Exchange 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) INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Send-Info: foo, bar Recv-Info: foo Bob checks the header field values, can support sending but not receiving "foo", and sending but not receiving "bar". Note that since Bob does not support receiving anything Alice can send, the response does not list any Recv-Info packages. SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Send-Info: foo 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. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 From: Alice ;tag=1234567 To: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 1 INVITE Contact: Send-Info: foo 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: Kaplan, et al. Expires - August 2008 [Page 19] The SIP INFO Method and Info Packages February 2008 INFO sip:alice@192.0.2.1 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Alice ;tag=1234567 From: Bob ;tag=abcdefg Call-Id: 123456mcmxcix CSeq: 2 INFO Contact: Info-Package: foo 11. Security Considerations There are no specific security issues for this mechanism, beyond those already applicable to SIP-based session signaling. In particular, if the SIP signaling is not protected from eavesdropping, authentication and repudiation, for example by using TLS transport, then the INFO request and its contents will not be protected either. Even with SIP/TLS, any SIP hop along the path from UAC to UAS can view, modify, or intercept INFO requests, as they can any SIP request. One interesting property of Info Package use is that the same digest-challenge mechanism used for INVITE-based authentication can be reused 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. 12. IANA Considerations This document will define an Info Package-type namespace, the specifics of which are TBD. Should this draft move forward, the body chosen for this coordination would be the Internet Assigned Numbers Authority (IANA). 13. Acknowledgements The authors wish to thank Brian Stucker, Francois Audet, Paul Kyzivat, Adam Roach, Eric Burger, and Robert Sparks for their suggestions and comments; and for Dean Willis, who was ahead of his time, having submitted a similar draft 5 years ago. Special thanks goes to Adam Roach for writing [RFC3265], from which several sections of text were directly copied into this draft. Kaplan, et al. Expires - August 2008 [Page 20] The SIP INFO Method and Info Packages February 2008 14. References 14.1. Normative References [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [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. 14.2. Informative References [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 [SIP-T] Vemuri, A., Peterson, J., "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", RFC 3372, September 2002. [RFC3428] Campbell, B., et al, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [CALLER-PREFS] Rosenberg, J., Schulzrinne, H., Kyzivat, P., "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC4028] Donavan, S., Rosenberg, J., "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [MSRP] Campbell, B., Mahy, R., Jennings, C., "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, February 2007 [info-harmful] Burger, E., "Session Initiation Protocol (SIP) INFO Method Use", draft-burger-sip-info-02.txt, November 2007. Kaplan, et al. Expires - August 2008 [Page 21] The SIP INFO Method and Info Packages February 2008 Authors' Addresses Hadriel Kaplan Acme Packet 71 Third Ave. Burlington, MA 01803 USA Email: hkaplan@acmepacket.com Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: christer.holmberg@ericsson.com Eric W. Burger BEA Systems, Inc. USA Email: eburger@standardstrack.com Kaplan, et al. Expires - August 2008 [Page 22] The SIP INFO Method and Info Packages February 2008 Full Copyright Statement Copyright (C) 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. Intellectual Property Statement 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kaplan, et al. Expires - August 2008 [Page 23]