SIP E. Burger Internet-Draft This Space For Sale Obsoletes: RFC 2976 H. Kaplan (if approved) Acme Packet Intended status: Standards Track C. Holmberg Expires: May 7, 2009 Ericsson November 3, 2008 Session Initiation Protocol (SIP) INFO Method and Package Framework draft-ietf-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/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 May 7, 2009. Abstract 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, also known as application level information, use these INFO requests. This draft addresses issues and open items from RFC 2976, and replaces it. Burger, et al. Expires May 7, 2009 [Page 1]
Internet-Draft INFO Framework November 2008 Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Be mindful of the terms User Agent Server (UAS) and User Agent Client (UAC). The text indicates where the sense of UAC/UAS refers to the INVITE-initiated dialog, as opposed to the sense of UAC/UAS for a particular invocation of the INFO method request. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Info Package Negotiation . . . . . . . . . . . . . . . . . . . 6 3.1. Info Package Negotiation Overview . . . . . . . . . . . . 6 3.2. UAC Negotiation Behavior . . . . . . . . . . . . . . . . . 9 3.3. UAS Negotiation Behavior . . . . . . . . . . . . . . . . . 10 3.4. Package Versions . . . . . . . . . . . . . . . . . . . . . 11 4. The INFO Method Request . . . . . . . . . . . . . . . . . . . 11 4.1. INFO Requests . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Responses to the INFO Request Method . . . . . . . . . . . 13 4.3. Behavior of SIP User Agents . . . . . . . . . . . . . . . 14 4.4. Behavior of Registrars . . . . . . . . . . . . . . . . . . 14 4.5. OPTIONS Processing . . . . . . . . . . . . . . . . . . . . 14 4.6. INFO Message Bodies . . . . . . . . . . . . . . . . . . . 15 5. Formal INFO Method Definition . . . . . . . . . . . . . . . . 16 5.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. INFO Headers . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. Info-Package header . . . . . . . . . . . . . . . . . 18 5.2.2. Send-Info header . . . . . . . . . . . . . . . . . . . 18 5.2.3. Recv-Info header . . . . . . . . . . . . . . . . . . . 18 6. Legacy Uses of INFO . . . . . . . . . . . . . . . . . . . . . 19 7. Info Package Considerations . . . . . . . . . . . . . . . . . 19 7.1. Appropriateness of Usage . . . . . . . . . . . . . . . . . 19 7.1.1. Dialog Fate-Sharing . . . . . . . . . . . . . . . . . 20 7.1.2. Messaging Rates and Volume . . . . . . . . . . . . . . 20 7.1.3. Is there a better alternative? . . . . . . . . . . . . 21 7.1.4. Alternatives for Common INFO Use . . . . . . . . . . . 22 7.2. Info Package Requirements . . . . . . . . . . . . . . . . 24 7.2.1. Applicability . . . . . . . . . . . . . . . . . . . . 24 7.2.2. Info Package Name . . . . . . . . . . . . . . . . . . 25 7.2.3. Info Package Parameters . . . . . . . . . . . . . . . 25 7.2.4. INFO Bodies . . . . . . . . . . . . . . . . . . . . . 25 7.2.5. UA generation of INFO requests . . . . . . . . . . . . 26 Burger, et al. Expires May 7, 2009 [Page 2]
Internet-Draft INFO Framework November 2008 7.2.6. UA processing of INFO requests . . . . . . . . . . . . 26 7.2.7. Rate of notifications . . . . . . . . . . . . . . . . 27 7.2.8. IANA Registrations . . . . . . . . . . . . . . . . . . 27 7.2.9. Examples . . . . . . . . . . . . . . . . . . . . . . . 27 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9.1. Update to Registration of SIP INFO Method . . . . . . . . 28 9.2. Registration of the Info-Package Header Field . . . . . . 28 9.3. Registration of the Recv-Info Header Field . . . . . . . . 29 9.4. Registration of the Send-Info Header Field . . . . . . . . 29 9.5. Creation of the Info Packages Registry . . . . . . . . . . 29 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Single Info Package . . . . . . . . . . . . . . . . . . . 30 10.2. Multipart INFO Example . . . . . . . . . . . . . . . . . . 31 10.3. Multiple INFO Body Example . . . . . . . . . . . . . . . . 32 11. Modifications to SIP Change Process . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 13.2. Informative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 37 Appendix B. Legacy INFO Usages . . . . . . . . . . . . . . . . . 38 B.1. ISUP . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.2. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.3. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.4. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.5. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 41 Burger, et al. Expires May 7, 2009 [Page 3]
Internet-Draft INFO Framework November 2008 1. Introduction The SIP protocol [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 [RFC4028]. The purpose of the INFO message [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 [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 as defined by RFC 2976 did not provide any context for the information that the request carried. 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 we need a well-defined and documented statement of what the information sent is for. This situation is identical to the context issue in Internet Mail [RFC3458]. RFC 3458 goes into this and other issues in detail. Event Packages [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 [RFC3265] package Burger, et al. Expires May 7, 2009 [Page 4]
Internet-Draft INFO Framework November 2008 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 Info-Package header indicates which package a particular INFO method request belongs to. There is a reserved Info Package, "nil", which indicates the UA conforms to this document, but does not wish to 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 3 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 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 [RFC2976]. 2. Applicability This draft proposes replacing the [RFC2976] SIP INFO method document Burger, et al. Expires May 7, 2009 [Page 5]
Internet-Draft INFO Framework November 2008 [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.] 3. Info Package Negotiation 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. 3.1. Info Package Negotiation Overview Info Package negotiation is an offer/offer mechanism. 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 its set of Send-Info and Recv-Info packages in the ACK. The UAC may choose 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 [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 [RFC3311], to name a few. The general rule is before a UA may begin sending INFO methods with a given Info Package, the sending UA must first indicate it wants to send the Info Package by listing it in a Send-Info header in the most recent dialog negotiation and the receiving UAS must positively indicate 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. If a UA conforming to this document does not wish to receive any Info Packages, the UA MUST indicate this by including a Recv-Info header with the value "nil". Likewise, if a UA does not wish to send any Info Packages, the UA MUST indicate this by including a Send-Info header with the value "nil". This enables the other UA to discern the difference between the first UA understanding Info Packages but Burger, et al. Expires May 7, 2009 [Page 6]
Internet-Draft INFO Framework November 2008 not wishing to receive any from a UA that does not understand Info Packages. A UA conforming to this document can always send or receive legacy INFO usages without packages. The UAC and UAS MUST NOT send an INFO message carrying Info Packages 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 way of saying the UAC may only send an INFO containing a given Info 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. 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 Send-Info: P, Q Recv-Info: P, R and the UAS responds Send-Info: P, T Recv-Info: Q, R 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 Burger, et al. Expires May 7, 2009 [Page 7]
Internet-Draft INFO Framework November 2008 Send-Info: P, Q Recv-Info: P, R and the UAS in a 200 OK responds Send-Info: P, T Recv-Info: Q, R and the UAC then confirms in an ACK with Send-Info: P, Q Recv-Info: T 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 Recv-Info: P, R, T 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 [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 [RFC3841] is not sufficient to determine if the endpoints support Info Packages, as the INFO method supported might be the obsolete RFC 2976 [RFC2976] version. For Info Packages, this draft does not provide a means of requiring 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 choose to not include the Send-Info and Recv-Info headers in its Burger, et al. Expires May 7, 2009 [Page 8]
Internet-Draft INFO Framework November 2008 initial INVITE message to a UAS, as described in the next section. 3.2. UAC Negotiation Behavior NOTE: In this section, UAC refers to the initiator of an INVITE- initiated dialog and not necessarily the UAC sending 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 a Send-Info header field with a value of "nil" 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. If 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 Burger, et al. Expires May 7, 2009 [Page 9]
Internet-Draft INFO Framework November 2008 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 a Send-Info header field with the value "nil", the UAS is indicating it will not send any, and if it contains a Recv-Info header field with the value "nil", 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. 3.3. UAS Negotiation Behavior NOTE: In this section, UAS refers to the recipient of an INVITE- initiated dialog and not necessarily the UAS receiving an INFO method request. 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 the value "nil". If the UAS rejects the UAC's INVITE request, the UAS MAY include its Info Package support in Send-Info and Recv-Info headers in its non- 1xx or 2xx responses. Burger, et al. Expires May 7, 2009 [Page 10]
Internet-Draft INFO Framework November 2008 3.4. Package Versions The protocol mechanism described herein does not provide for a package versioning mechanism. This is for two reasons. The first is that if an Info Package has a capability for forward and backward compatibility in the Info Package payload, then that compatibility comes from the application level semantics of the information. This means it is the responsibility of the application to hanle such compatibility and not the INFO framework. For example, one could use XML versioning techniques in the payload to indicate verisons of the Info Package. The second reason we do not have a package versioning system is if the payload is not sufficient to carry payload versions, then it is highly unlikely payloads would be backwards compatible. That is, what one really is defining is a new Info Package. This is more especially so when one considers User Agents can negotiate package support but cannot negotiate package version support. 4. The INFO Method Request 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. 4.1. INFO Requests The INFO method communicates application level information along the signaling path for the call. The INFO method MUST NOT change the state of sessions initiated by SIP. 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 for a discussion of this. The UAC MUST include the Info-Package header field when it sends an INFO request carrying an Info Package. The Info-Package header field value in an INFO request contains a single Info Package token. If the UAC is sending multiple Info Packages in the INFO request, the UAC MUST include the appropriate Info-Package headers, one header per package, as described below. If the UAS indicated support for the INFO method and Info Packages as described in this document by the Burger, et al. Expires May 7, 2009 [Page 11]
Internet-Draft INFO Framework November 2008 presence of a Recv-Info header field during negotiation, 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 or dialog modification transaction for the UAS in response to the UAC. In other words, one can only send what the other end is willing to receive. The SOLE exception to this rule is if the UAC wishes to send an INFO in a legacy usage context. In this case, if the UAS has never offered a Recv-Info header or never offered a Recv-Info header with a package of a similar function to the legacy INFO usage, the UAC MAY send an INFO without an Info- Package header field and a body appropriate to the said legacy usage. If the payload of the INFO method has multiple body parts, the UAC SHOULD identify which body part belongs to a given Info Package. The UAC does this by adding the modifier ";cid=<identifier>" to the Info- Package header field value, where "<identifier>" is the Content-ID MIME header value corresponding to the body part associated with the Info-Package. The sole exception to this rule is if the particular Info Package carries no payload. In this case there will be no body part associated with the Info Package and thus there will be no Content-ID to reference. In this case, the UAC MUST NOT include the "cid" modifier. In such a manner, the UAC MAY bundle multiple Info Package payloads in a single INFO method request. Note there is no relationship between the order of Info-Package headers and the location of the corresponding INFO bodies. There are a number of issues to keep in mind when one bundles multiple Info Packages in a single INFO request. 1. Recall the response code to an INFO method request relates to the INFO method request itself, and not the application level semantics encoded by the Info Package. Thus if the INFO method request is well formed and correct, the proper response from the UAS MUST be a 200 OK. If there is an error at the application level, the application has the responsibility of taking corrective action. 2. If one Info Package payload is correct but another Info Package payload is malformed at the protocol level and the Content- Disposition includes handling=required [RFC3459], then the entire message fails. 3. From the perspective of the INFO method request, there is nothing special, unique, or inferred by having multiple Info Packages transported in a single INFO method request. There is no difference between, for example, transporting three Info Package payloads as a multipart/mime in a single INFO method request and three separate INFO method requests transporting the corresponding Info Package payloads. Burger, et al. Expires May 7, 2009 [Page 12]
Internet-Draft INFO Framework November 2008 Since there is the potential for carrying a multipart/mime body, User Agents MUST conform to RFC 3261 as updated by body-handling [I-D.ietf-sip-body-handling] to support multipart MIME handling. 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 [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. 4.2. Responses to the INFO Request Method 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 Info-Package 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 response. 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. Burger, et al. Expires May 7, 2009 [Page 13]
Internet-Draft INFO Framework November 2008 NOTE: Some may think "Bad Event" implies there is a link between INFO and NOTIFY. However, what this does is refine 489 to mean, "received some package in some context that I do not understand," where today the possible contexts are INFO and NOTIFY. The text is irrelevant and the meaning is clear from the context. 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. 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 RFC 3261 [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 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 [RFC5057], which may cause the INVITE dialog to terminate. 4.4. Behavior of Registrars Registrars receiving a REGISTER request that includes Send-Info and Recv-Info headers MAY store such information and use it for routing purposes. How the registrar uses this information is beyond the scope of this document. 4.5. OPTIONS Processing A UAC, the sender of the OPTIONS request, MAY include Send-Info and Recv-Info headers, populated appropriately for the packages the UAC Burger, et al. Expires May 7, 2009 [Page 14]
Internet-Draft INFO Framework November 2008 supports. The UAS MAY include its set of Send-Info and Recv-Info packages. The UAS and UAC MUST NOT consider the OPTIONS request to be part of a capabilities negotiation. The OPTIONS request is purely a probe. For the UAC or UAS to renegotiate package support, they must use the procedures described in Section 3. 4.6. INFO Message Bodies 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 for overlapping INFO requests. That is, when the UAC sends another INFO request before receiving a transaction response from the UAS to a prior INFO request. While the UAC will increment the CSeq header upon the transmission of new INFO messages, the UAS cannot use the CSeq to determine the sequence of INFO information. 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. Because there are numerous situations where a SIP method request can carry a payload, any INFO method may contain body parts in addition to the payload associated with the Info Package. Following MIME [RFC2046], if there are multiple body parts, the UAC MUST package the body part in a multipart/mime. The UAC MUST identify the body part associated with an Info-Package by including a Content-ID header [RFC2045]. The UAC MUST identify the payload by including the cid modifier to the associated Info-Package header, with the value of the Content-ID. If there is no payload associated with the Info Package, the UAC MUST NOT include a cid modifier. The UAC MAY include multiple Info Packages and Info Package payloads by bundling the Info Package payloads in a multipart/mime and associating the payloads with the packages by using the Content-ID as described in the paragraph above. If the UAC bundles multiple Info Packages in a single INFO request, the UAC MUST enumerate each Info Package in a separate Info-Package header. Burger, et al. Expires May 7, 2009 [Page 15]
Internet-Draft INFO Framework November 2008 5. Formal INFO Method Definition 5.1. INFO Method This document describes one new SIP method: INFO. This document replaces the definition and registrations found in [RFC2976]. This table expands on tables 2 and 3 in [RFC3261]. Table 1: Summary of Header Fields Header Where INFO ------ ----- ---- Accept R o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415 c Allow R o Allow 200 - Allow 405 o Allow-Events R o Allow-Events r o Authentication-Info 2xx o Authorization R o Call-ID gc m Call-Info R o Call-Info r o Contact R o Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Disposition e o Content-Encoding e o Content-Language e o Content-Length e o Content-Type e * CSeq gc m Date g o Error-Info 3xx-6xx o Expires g - From gc m Geolocation R o Max-Breadth R o Max-Forwards R o MIME-Version R o Burger, et al. Expires May 7, 2009 [Page 16]
Internet-Draft INFO Framework November 2008 MIME-Version r o Organization g o Privacy R o Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx o Require R o Require r o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Route R o Security-Client R o Security-Server 421,494 o Security-Verify R o Server r o Subject R o Supported R o Supported 2xx 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 Figure 1 5.2. INFO Headers This table expands on tables 2 and 3 in [RFC3261]. Burger, et al. Expires May 7, 2009 [Page 17]
Internet-Draft INFO Framework November 2008 Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT -------------------------------------------------------------------- Info-Package R - - - - - - - m - - - - 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 - - - - - - - 5.2.1. Info-Package header 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 [RFC5226]. There MUST be exactly one Info Package type listed per Info-Package header. Multiple Info-Packages transported in a given INFO method request REQUIRE multiple Info-Package headers, one per Info-Package conveyed by the given INFO method request. 5.2.2. Send-Info header This document adds Send-Info to the definition of the element "general-header" in the SIP [RFC3261] message grammar. Section 3 describes the Send-Info header usage. 5.2.3. Recv-Info header This document adds Recv-Info to the definition of the element "general-header" in the SIP [RFC3261] message grammar. Section 3 describes the Recv-Info header usage. Burger, et al. Expires May 7, 2009 [Page 18]
Internet-Draft INFO Framework November 2008 6. Legacy Uses of INFO Several RFC-defined and other standards-defined uses of RFC 2976 INFO [RFC2976] exist and are in use, as well as numerous proprietary uses. Appendix B describes some of these usages. 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 [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. 7. Info Package Considerations This section covers several issues which one should take into consideration when propsing new Info Packages. 7.1. Appropriateness of Usage 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 Burger, et al. Expires May 7, 2009 [Page 19]
Internet-Draft INFO Framework November 2008 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. 7.1.1. Dialog Fate-Sharing INFO, by design, is a method within an INVITE dialog usage. RFC 5057 [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. 7.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 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 [RFC0768]. Appropriate mechanisms for such traffic include MSRP [RFC4975], COMEDIA [RFC4145], or HTTP [RFC2616]. Burger, et al. Expires May 7, 2009 [Page 20]
Internet-Draft INFO Framework November 2008 7.1.3. Is there a better alternative? The first alternative for application level interaction is SIP Events, also known as SUBSCRIBE/NOTIFY [RFC3265]. In this model, a user agent requests state information, such as key pad presses from a device to an application server or key map images from an application server to a device. The SUBSCRIBE creates a new dialog that does not share the fate of the related INVITE-initiated dialog. Moreover, using the SUBSCRIBE model enables multiple applications to receive state updates. These applications can be outside the media path and potentially outside the INVITE-initiated dialog's proxy path. Implementers do need to be aware the price of having a protocol that works in all cases, can scale, can easily load balance, and will not mysteriously fail a session in the event of state synchronization failure does come at a cost. Session establishment is a minimum of two messages in addition to the INVITE dialog establishment. If the SUBSCRIBE application is co-resident with the INVITE application, the application will have to manage two SIP dialogs instead of one. Tracking the application level state dominates memory and processing for some applications, and as such the doubling of SIP dialogs is not an issue. However, for other applications, this may be an issue. The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user. Another model for application level information exchange is to establish a communication channel. One model for this is MRCPv2 [I-D.ietf-speechsc-mrcpv2]. Here, the INVITE-initiated dialog establishes a separate reliable, connection-oriented channel, such as a TCP [RFC0793] or SCTP [RFC4960] stream. One uses SIP to locate the remote endpoint, but uses a direct connection for the UUI. One then can create whatever protocol one wishes, whether from scratch (as in MRCPv2) or using a substrate such as BEEP [RFC3080]. Another model is to use a totally externally signaled channel, such as HTTP [RFC2616]. In this model, the user agent knows about a rendezvous point to direct HTTP requests to for the transfer of information. Examples include encoding of a prompt to retrieve in the SIP Request URI in RFC 4240 [RFC4240] or the encoding of a SUBMIT target in a VoiceXML [W3C.REC-voicexml21-20070619] script. MSRP [RFC4975] defines session-based instant messaging as well as 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. Burger, et al. Expires May 7, 2009 [Page 21]
Internet-Draft INFO Framework November 2008 A common reason people in the past used INFO for application level information exchange is the negotiation is very lightweight compared to SUBSCRIBE/NOTIFY. This is more especially so if it is not certain if there will be application level information exchange. The SUBSCRIBE/NOTIFY machinery requires the user agents to exchange rich capabilities and maintain state for additional SIP dialogs. However, this is a weak argument if there is a high likelihood of application level information exchange. In this case, we recommend the use of a more robust application level information exchange protocol. 7.1.4. Alternatives for Common INFO Use What alternatives to INFO are there for UA-to-UA application session signaling? As noted above, there are three broad classes of session signaling available. The choice depends on the circumstances. Following is a list of situations that have used INFO in the past. o State updates o User stimulus o Direct signaling channel o Proxy-aware signaling o Dialog probe 7.1.4.1. State Updates This is the broad class of one User Agent updating another with changes in state. The design goal of the SUBSCRIBE/NOTIFY [RFC3265] event framework is to meet just this need. 7.1.4.2. User Stimulus: Touch Tones and Others This is the class of the user entering stimulus at one User Agent, and the User Agent transporting that stimulus to the other. A key thing to realize is key presses on the telephone keypad is user stimulus. Thus, the appropriate mechanism to use here is KPML [RFC4730]. 7.1.4.3. Direct Signaling Channel State updates and user stimulus tend to have relatively few messages per session. Sometimes, User Agents need to exchange a relatively high number of messages. 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. In this case, establishing a separate, direct control channel, as in MSRP [RFC4975] or MRCPv2 [I-D.ietf-speechsc-mrcpv2] is appropriate. Burger, et al. Expires May 7, 2009 [Page 22]
Internet-Draft INFO Framework November 2008 In addition, not every situation requires a SIP solution. Some signaling is really just one-shot to third-party endpoints. That situation may better be handled using an appropriate protocol, such as HTTP [RFC2616]. 7.1.4.4. Proxy-Aware Signaling Sometimes, one does want proxies to be in the signaling path for UA- to-UA application signaling. In this case, the use of a SIP request is appropriate. To date, there are no mechanisms for completely disambiguating INFO requests. For example, one could create a registry of INFO packages. The definition of the package would define the contexts for the various MIME Content-Types, as well as the context of the request itself. However, a package can have multiple content types. Moreover, having the context, or package identifier, at the SIP level precludes bundling multiple contexts responding in the same INFO request. For example, a User Agent might want to bundle two different responses in a multipart/mixed MIME body type. Because there is no difference in either the protocol machinery or registration process due to these factors, we will not create an INFO framework. If one needs a SIP User Agent-to-SIP User Agent application session signaling transport protocol that touches all Record-Route proxies in a path, one MUST create a new SIP method as described in Section 27.4 of RFC 3261 [RFC3261]. 7.1.4.5. Dialog Probe Some implementations in the wild use INFO to probe if an INVITE- initiated dialog is alive. While this works, it is NOT RECOMMENDED. In particular, RFC 4028 [RFC4028] describes how to ensure an INVITE- initiated dialog is alive. 7.1.4.6. Malicious Indicator Take the case of Malicious Indicator. This is where a subscriber receives a call, realizes it is a malicious call (threatening, SPIT, etc.). They then press the SPIT button (or press *xx), which tells their service provider to mark the UAC as a bad actor. One might be tempted to think that INFO would be a great option for this service. It follows the return path of the INVITE, and so the INFO will hit the caller's inbound proxy, which it can learn the caller is (statistically) a bad actor. That way the inbound proxy can do stuff like notify law enforcement, add a vote to "this is a SPIT source," or other useful action. However, consider a few issues. First, since INFO lives exclusively Burger, et al. Expires May 7, 2009 [Page 23]
Internet-Draft INFO Framework November 2008 within an established dialog, there is no way to assert this message after the call completes. Second, this mechanism relies on an active service provider topology. If there is no proxy in the chain that will eat the INFO, the caller will see the "this is a bad guy" message, which may have consequences in the real world. Third, there is no a'priori way for the UAS to know whether or not it can issue the INFO. The caller certainly will not advertise, "please tell me if I am bad, particularly I know in advance that I *am* a bad actor." One approach is for the service provider's proxy to SUBSCRIBE for the SPIT event at the UAS. At this point, life is good, interoperable, and works across networks. This enables events after the dialog is torn down, as presumably the SPIT event will refer not to, "this dialog," which does not exist, but to "that dialog identifier," which exists (and is theoretically unique) forever. Another approach that saves considerably on the overhead of subscriptions would be for the service provider to insert a HTTP URI in the initial INVITE, noting it is for reporting malicious behavior. When the subscriber presses the SPIT button, an HTTP POST gets executed, delivering the call information to the service provider. The service provider can encode basic call information in the HTTP URI and can instruct the device to send whatever arbitrary data is necessary in the POST. This method has the added benefit of being entirely outside the real-time SIP proxy network. 7.2. Info Package Requirements 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. 7.2.1. Applicability 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 Burger, et al. Expires May 7, 2009 [Page 24]
Internet-Draft INFO Framework November 2008 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. 7.2.2. Info Package Name 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. 7.2.3. Info Package Parameters 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. 7.2.4. INFO Bodies 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. [OPEN ISSUE: Do we require a UAS to enumerate every MIME type associated with the Info Packages advertised in the UAS' Recv-Info header? I see two schools of thought on this one: 1. Follow full RFC 3261: the UAS MUST enumerate every MIME type associated with the Info Packages advertised in the UAS' Recv-Info header the UA is willing to receive. If a UAC sends a body that includes something not enumerated by the UAS, this is a protocol error and the UAS should barf appropriately. 2. Follow the text as is, where the specification of an Info Package in Recv_Info (and the corresponding advertisement in Send_Info) includes an implicit set of MIME types associated with the said package. Pros of #1: a. Cannot be wrong following RFC 3261 b. Provides a protocol mechanism for negotiating MIME types c. Lets a UAC know whether the UAS can process a particular MIME type the UAC wishes to send (refinement of (b) above). For example, if the package sends images, it would be helpful for the UAC to know it can send image/jpeg but it cannot send image/png Burger, et al. Expires May 7, 2009 [Page 25]
Internet-Draft INFO Framework November 2008 Cons of #1: a. The Accept header can grow to be very, very, very, very, very long. b. There is no way to associate the MIME type in the Accept header with a particular package. That is, the UAC may advertise image/jpeg and image/png. The UAS may accept image/png for icons but image/jpeg for applications. There is no way to communicate this to the UAC. Pros of #2: a. Accept header does not grow without bound b. No worse from a protocol perspective than Con #1(b). Cons of #2: a. Does not strictly follow RFC 3261] 7.2.5. UA generation of INFO requests 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. The Info Package MAY allow overlapping (outstanding) INFO requests. If the package does not allow overlapping INFO requests, the Info Package MUST disclose this in the section describing UA generation of INFO requests. Note the generic protocol machinery of the INFO method has no way of enforcing such a requirement. Section 7.2.6 describes this situation. This section MAY describe the behavior used to process the subsequent response. 7.2.6. UA processing of INFO requests 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. If the info Package does not permit overlapping INFO requests, it is important to note the issuance of overlapping INFO requests is an application-layer protocol failure and not an INFO method failure. In the event a UAC issues overlapping INFO requests for an Info Package, this does not consitute an INFO protocol failure. If the INFO request is well formed in all other respects, the UAS MUST NOT return an error response. Burger, et al. Expires May 7, 2009 [Page 26]
Internet-Draft INFO Framework November 2008 7.2.7. Rate of notifications 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. 7.2.8. IANA Registrations The Info Package MUST have an IANA Considerations section that includes definitions for Package Name and supported MIME types. 7.2.9. Examples 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. 8. Syntax 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 [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 [RFC3261]. See SIP for any elements not defined in this section. Burger, et al. Expires May 7, 2009 [Page 27]
Internet-Draft INFO Framework November 2008 INFOm = %x49.4E.46.4F ; INFO in caps extension-method = INFOm / token Info-Package = "Info-Package" HCOLON Info-package-type [ ";" "cid" "=" token ] Send-Info = "Send-Info" HCOLON "nil" / Info-package-type *( COMMA Info-package-type ) Recv-Info = "Recv-Info" HCOLON "nil" / Info-package-type *( COMMA Info-package-type ) Info-package-type = Info-package-name *( "." Info-package-param) Info-package-name = token-nodot Info-package-param = token-nodot token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) 9. IANA Considerations 9.1. Update to Registration of SIP INFO Method Please update the existing registration in the SIP Methods and Response Codes registry under the SIP Parameters registry that states: Method: INFO Reference: [RFC2976] to: Method: INFO Reference: [RFCXXXX] [RFC EDITOR NOTE: Please replace RFCXXXX with the designation for this document.] 9.2. Registration of the Info-Package Header Field Please add the following new SIP header field in the Header Fields subregistry under the SIP Parameters registry. Burger, et al. Expires May 7, 2009 [Page 28]
Internet-Draft INFO Framework November 2008 Header Name: Info-Package Compact Form: (none) Reference: [RFCxxxx] [RFC EDITOR NOTE: Please replace RFCXXXX with the designation for this document.] 9.3. Registration of the Recv-Info Header Field Please add the following new SIP header field in the Header Fields subregistry under the SIP Parameters registry. Header Name: Recv-Info Compact Form: (none) Reference: [RFCxxxx] (postamble) [RFC EDITOR NOTE: Please replace RFCXXXX with the designation for this document.] 9.4. Registration of the Send-Info Header Field Please add the following new SIP header field in the Header Fields subregistry under the SIP Parameters registry. Header Name: Send-Info Compact Form: (none) Reference: [RFCxxxx] [RFC EDITOR NOTE: Please replace RFCXXXX with the designation for this document.] 9.5. Creation of the Info Packages Registry Please create a subregistry in the SIP Parameters registry with the following data elements. Per RFC 5226 [RFC5226], this registry is Specification Required. The Info Package Name is a token, taken from the ABNF of RFC 3261 [RFC3261]. The MIME Types are zero or more MIME Types from the MIME Type Registry. The Reference is the published specification describing the Info Package. This document reserves the Info Package Name "nil" to represent "no Info Package present" and as such IANA shall not honor a request to register the "nil" Info Package. Burger, et al. Expires May 7, 2009 [Page 29]
Internet-Draft INFO Framework November 2008 Info Package Name Info Package Payload MIME Types Reference 10. Examples 10.1. Single Info Package 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 <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 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 a nil Recv-Info header. 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: nil 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. Burger, et al. Expires May 7, 2009 [Page 30]
Internet-Draft INFO Framework November 2008 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: nil 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: 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 10.2. Multipart INFO Example This is for where there is a single INFO payload in a multipart/mime. Burger, et al. Expires May 7, 2009 [Page 31]
Internet-Draft INFO Framework November 2008 INFO .... To: .... From: .... Info-Package: foo;cid=abcd1234zz Mumble: <cid:abcd9999qq> Content-Type: multipart/mixed;boundary="theboundary" ... --theboundary Content-Type: application/mumble Content-Id: abcd9999qq ... <mumble stuff> --theboundary Content-Type: application/foo Content-Id: abcd1234zz <foo body> --theboundary-- 10.3. Multiple INFO Body Example Note that by using the cid modifier to the Info-Package header, order does not matter in the multipart. Burger, et al. Expires May 7, 2009 [Page 32]
Internet-Draft INFO Framework November 2008 INFO .... To: .... From: .... Info-Package: foo;cid=abcd1234zz Info-Package: bar;cid=wxyz9876 Content-Type: multipart/mixed;boundary="theboundary" ... --theboundary Content-Type: application/bar Content-Id: wxyz9876 ... <bar stuff> --theboundary Content-Type: application/foo Content-Id: abcd1234zz <foo body> --theboundary-- 11. Modifications to SIP Change Process [EDITOR'S NOTE: This section may become a separate document in the future.] This document updates RFC 3427 [RFC3427] to add a process for registering new Info Packages. The process for registering new Info Packages follows the process outlined in Section 4.3 of RFC 3427 for the registration of SIP Event Packages. Namely, the registration of a new SIP Info Package requires the SIPPING chairs to assign an individual to perform expert review of the proposal if the work is not a SIPPING work item in itself. 12. Security Considerations 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 this document's clarification of the use of INFO to improve the security of the Internet. If the content of the Info Package payload is private, User Agents will need to use end-to-end encryption, such as S/MIME, to prevent access to the content. This is particularly important as transport Burger, et al. Expires May 7, 2009 [Page 33]
Internet-Draft INFO Framework November 2008 of INFO is likely not to be end-to-end, but through SIP proxies and back-to-back user agents (B2BUA's), which the user may not trust. 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. 13. References 13.1. Normative References [I-D.ietf-sip-body-handling] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", draft-ietf-sip-body-handling-04 (work in progress), October 2008. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [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. Burger, et al. Expires May 7, 2009 [Page 34]
Internet-Draft INFO Framework November 2008 [RFC3459] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 13.2. Informative References [I-D.ietf-speechsc-mrcpv2] Shanmugham, S. and D. Burnett, "Media Resource Control Protocol Version 2 (MRCPv2)", draft-ietf-speechsc-mrcpv2-17 (work in progress), November 2008. [I-D.saleem-msml] Saleem, A., "Media Server Markup Language (MSML)", draft-saleem-msml-07 (work in progress), August 2008. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. Burger, et al. Expires May 7, 2009 [Page 35]
Internet-Draft INFO Framework November 2008 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005. [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. [RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, "Interworking between the Session Initiation Protocol (SIP) and QSIG", BCP 117, RFC 4497, May 2006. [RFC4730] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)", RFC 4730, November 2006. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server Control Markup Language (MSCML) and Protocol", RFC 5022, September 2007. [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session Burger, et al. Expires May 7, 2009 [Page 36]
Internet-Draft INFO Framework November 2008 Initiation Protocol", RFC 5057, November 2007. [W3C.REC-voicexml21-20070619] Porter, B., McGlashan, S., Lee, A., Burnett, D., Carter, J., Oshry, M., Bodell, M., Baggia, P., Rehor, K., Burke, D., Candell, E., and R. Auburn, "Voice Extensible Markup Language (VoiceXML) 2.1", World Wide Web Consortium Recommendation REC-voicexml21-20070619, June 2007, <http://www.w3.org/TR/2007/REC-voicexml21-20070619>. Appendix A. Acknowledgements 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. Keith Drage gave lots of excellent comments and helped emensely with Figure 1. 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, Andrew Allen, Adam Roach, Anders Kristensen, Gordon Beith, Ben Campbell, Bob Penfield, Keith Drage, Jeroen van Bemmel, Mary Barnes, and Salvatore Loreto. Burger, et al. Expires May 7, 2009 [Page 37]
Internet-Draft INFO Framework November 2008 However, any errors are still our own. Appendix B. Legacy INFO Usages [OPEN ISSUE: We could create a registry of INFO Usages. However, since that does not really improve interoperablity, it is not clear it is worth gearing up IANA to follow this.] [OPEN ISSUE: This appendix could very well be its own stand-alone document. Should it be?] We do not intend this section to be a comprehensive catalog of INFO usages. However, it should give the reader a flavor for current INFO usages. B.1. ISUP SIP-T uses Content-Type to identify ISUP protocol elements in an INFO message. See RFC3372 [RFC3372]. B.2. QSIG QSIG uses Content-Type to identify QSIG protocol elements in an INFO message. See RFC4497 [RFC4497]. B.3. MSCML MSCML uses a Require to ensure the UAS understands that INFO messages of the MSCML type are in fact MSCML messages. See RFC5022 [RFC5022]. B.4. MSML MSML endpoints just know the INFO messages carry MSML and from the Content-Type of the given INFO method request. See the MSML [I-D.saleem-msml] draft. B.5. DTMF [EDITOR'S NOTE: Are there public references? The AS5300 documentation from Cisco describes Cisco's use of INFO to carry DTMF. Anyone else want to belly up to the bar and have us collect your proprietary DTMF INFO payload here?] Appendix C. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from -00 Burger, et al. Expires May 7, 2009 [Page 38]
Internet-Draft INFO Framework November 2008 o Corrected ABNF. o Enabled sending of legacy INFO messages. Receiving legacy INFO messages was already here. o Negotiation is not Offer/Answer, it is Offer/Offer. o Created the explicit "nil" Info Package to indicate no info package. o Fixed CANCEL impacting future transactions. o Added Registrar behavior. o Added OPTIONS processing. o Clarified overlapping INFO method processing. o Described multiple INFO bodies in a single INFO method. o Took out Info-Package as a header for responses to the INFO method. o Expanded on risks of using INFO and filled-in more on the alternatives o Moved definitions of INFO into the body of the text and cleaned up IANA Considerations section o Added legacy usages descriptions Authors' Addresses Eric W. Burger This Space For Sale 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: Burger, et al. Expires May 7, 2009 [Page 39]
Internet-Draft INFO Framework November 2008 Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland Phone: Fax: Email: christer.holmberg@ericsson.com URI: Burger, et al. Expires May 7, 2009 [Page 40]
Internet-Draft INFO Framework November 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 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. Burger, et al. Expires May 7, 2009 [Page 41]
