SIPCORE C. Holmberg Internet-Draft Ericsson Obsoletes: 2976 (if approved) E. Burger Intended status: Standards Track NeuStar, Inc. Expires:November 20, 2010April 1, 2011 H. Kaplan Acme PacketMay 19,September 28, 2010 Session Initiation Protocol (SIP) INFO Method and Package Frameworkdraft-ietf-sipcore-info-events-08draft-ietf-sipcore-info-events-09 Abstract This document defines a method, INFO, for the Session Initiation Protocol (SIP), and an Info Package mechanism. The document obsoletes RFC 2976. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. 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]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire onNovember 20, 2010.April 1, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.ApplicabilityMotivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability and Backward Compatibility . . . . . . . . . . . 6 4. The INFO Method . . . . . . . . . . . . . . . . . . . . . . .5 3.1.6 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . .5 3.2.6 4.2. INFO Request . . . . . . . . . . . . . . . . . . . . . .5 3.2.1.6 4.2.1. INFO Request Sender . . . . . . . . . . . . . . . . .5 3.2.2.7 4.2.2. INFO Request Receiver . . . . . . . . . . . . . . . .6 3.2.3.8 4.2.3. SIP Proxies . . . . . . . . . . . . . . . . . . . . .7 3.3.8 4.3. INFO Message Body . . . . . . . . . . . . . . . . . . . .7 3.3.1.8 4.3.1. INFO Request Message Body . . . . . . . . . . . . . .7 3.3.2.8 4.3.2. INFO Response Message Body . . . . . . . . . . . . . .7 3.4.9 4.4. Order of Delivery . . . . . . . . . . . . . . . . . . . .8 4.9 5. Info Packages . . . . . . . . . . . . . . . . . . . . . . . .8 4.1.9 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . .8 4.2.9 5.2. User Agent Behavior . . . . . . . . . . . . . . . . . . .8 4.2.1.10 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . .8 4.2.2.10 5.2.2. UA Procedures . . . . . . . . . . . . . . . . . . . .8 4.2.3.10 5.2.3. Recv-Info header field rules . . . . . . . . . . . . .10 4.2.4.11 5.2.4. Info Package fallback rules . . . . . . . . . . . . .10 4.3.12 5.3. REGISTER Processing . . . . . . . . . . . . . . . . . . .11 5.12 6. Formal INFO Method Definition . . . . . . . . . . . . . . . .11 5.1.13 6.1. INFO Method . . . . . . . . . . . . . . . . . . . . . . .11 6.13 7. INFO Header Fields . . . . . . . . . . . . . . . . . . . . . .13 6.1.14 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . .13 6.2.14 7.2. Info-Package header field . . . . . . . . . . . . . . . .14 6.3.15 7.3. Recv-Info header field . . . . . . . . . . . . . . . . .14 7.16 8. Info Package Considerations . . . . . . . . . . . . . . . . .14 7.1.16 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . .14 7.2.16 8.2. Appropriateness of Info Package Usage . . . . . . . . . .14 7.3.16 8.3. Alternative Mechanisms . . . . . . . . . . . . . . . . .15 7.3.1.16 8.3.1. Alternative SIP signaling plane mechanisms . . . . . .15 7.3.2.16 8.3.2. Media Plane Mechanisms . . . . . . . . . . . . . . . .16 7.3.3.18 8.3.3. Non-SIP related mechanisms . . . . . . . . . . . . . .17 8.19 9. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Legacy INFO Usage . . . . . . . . . . . . . . . . . . . . . . 1819 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . .1819 9.2.Problems . . .ABNF . . . . . . . . . . . . . . . . . . . . .18 9.3. Co-existence with Info Package based INFO usage. . . . . 19 10. Info Package Requirements . . . . . . . . . . . . . . . . . . 19 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Overall Description . . . . . . . . . . . . . . . . . . . 20 10.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 20 10.4. Info Package Name . . . . . . . . . . . . . . . . . . . .2021 10.5. Info Package Parameters . . . . . . . . . . . . . . . . . 21 10.6. SIP Option Tags . . . . . . . . . . . . . . . . . . . . . 21 10.7. INFO Message Body Parts . . . . . . . . . . . . . . . . .2122 10.8. Info Package Usage Restrictions . . . . . . . . . . . . . 22 10.9. Rate of INFO Requests . . . . . . . . . . . . . . . . . . 22 10.10. Info Package Security Considerations . . . . . . . . . .2223 10.11. Implementation Details . . . . . . . . . . . . . . . . . 23 10.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11.1. Update to Registration of SIP INFO Method . . . . . . . . 23 11.2. Registration of the Info-Package header field . . . . . . 24 11.3. Registration of the Recv-Info header field . . . . . . . 24 11.4. Creation of the Info Packages Registry . . . . . . . . . 24 11.5. Registration of the Info-Package Content-Disposition . . 25 11.6. SIP Response Code 469 Registration . . . . . . . . . . . 25 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Indication for which Info Packages UAs are willing to receive INFO requests . . . . . . . . . . . . . . . . . . 25 12.1.1. Initial INVITE request . . . . . . . . . . . . . . . . 25 12.1.2. Target refresh . . . . . . . . . . . . . . . . . . . . 26 12.2. INFO request associated with Info Package . . . . . . . . 27 12.2.1. Single payload . . . . . . . . . . . . . . . . . . . . 27 12.2.2. Multipart INFO . . . . . . . . . . . . . . . . . . . .2728 13. Security Considerations . . . . . . . . . . . . . . . . . . .3031 14. References . . . . . . . . . . . . . . . . . . . . . . . . . .3132 14.1. Normative References . . . . . . . . . . . . . . . . . .3132 14.2. Informative References . . . . . . . . . . . . . . . . .3132 Appendix A.Legacy INFO Usage . . . . . . . . . . . . . . . . . . 33 A.1. General . . . . .Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix B. Change Log . .33 A.2. ISUP. . . . . . . . . . . . . . . . . . .. . . . . . . 33 A.3. QSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.4. MSCML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.5. MSML . . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.6. Video Fast Update . . . . . . . . . . . . . . . . . . . . 34 A.7. DTMF . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 34 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261]. The purpose of the INFO message is to carry application level information between endpoints, using the SIP dialog signaling path. Note that the INFO method is not used to update characteristics of a SIP dialog or session, but to allow the applications which use the SIP session to exchange information (which might update the state of those applications). Use of the INFO method does not constitute a separate dialog usage. INFO messages are always part of, and share the fate of, an invite dialog usage [RFC5057]. INFO messages cannot be sent as part of other dialog usages, or outside an existing dialog. This document also defines an Info Package mechanism. An Info Package specification defines the content and semantics of the information carried in an INFO message associated with the Info Package. The Info Package mechanism also provides a way for UAs to indicate for which Info Packages they are willing to receive INFO requests, and which Info Package a specific INFO request is associated with. A UA uses the Recv-Info header field, on a per-dialog basis, to indicate for which Info Packages it is willing to receive INFO requests. A UA can indicate an initial set of Info Packages during dialog establishment and can indicate a new set during the lifetime of the invite dialog usage. NOTE: A UA can use an empty Recv-Info header field (a header field without a value) to indicate that it is not willing to receive INFO requests for any Info-Package, but to inform other UAs that it still supports the Info Package mechanism. When a UA sends an INFO request, it uses the Info-Package header field to indicate which Info Package is associated with the request. One particular INFO request can only be associated with a single Info Package. 2.Applicability This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" modeMotivation A number ofusageapplications, standardized and proprietary, make use of the INFO methodthat is compatible with the usageas it was previously defined in RFC 2976 [RFC2976], referred to as "legacy INFOUsage" in this document. 3. The INFO Method 3.1. General The INFO method provides a mechanism for transporting application level information that can further enhance a SIP application. Annex A gives more details onusage". These include but are not limited to: o RFC 3372 [RFC3372] specifies thetypesencapsulation ofapplications for whichISDN User Part (ISUP) in SIP message bodies. ITU-T and 3GPP have specified similar procedures. o [Ecma-355] specifies theuseencapsulation ofINFO is appropriate. This section describesQSIG in SIP message bodies. o RFC 5022 [RFC5022] specifies howa UA handlesINFOrequests and responses, as wellis used asthe message bodies included in INFO messages. 3.2. INFO Request 3.2.1. INFO Request Sender An INFO request can be associated with an Info Package (see Section 4), or associated withalegacy INFO usage (see Section 9). The construction of the INFO request istransport mechanism by thesame as any other non- target refresh request withinMedia Server Control Markup Language (MSCML) protocol. MSCML uses anexisting invite dialog usage as describedoption-tag inSection 12.2 of [RFC3261]. When a UA sends an INFO request associated with an Info Package, it MUST include an Info-Packagethe Require header field to ensure thatindicates which Info Package is associated withtherequest. A specificreceiver understands the INFOrequest can becontent. o RFC 5707 [RFC5707] specifies how INFO us usedonly for a single Info Package. Whenas aUA sends an INFO request associated with an legacy INFO usage there is no Info Package associated with the request, and the UA MUST NOT include an Info-Package header field intransport mechanism by therequest. TheMedia Server Markup Language (MSML) protocol. o Companies have been using INFO messages in order to requestMUST NOT containfast video update. Currently aRecv-Info header field. Astandardized mechanism, based on RTCP, has been specified in RFC 5168 [RFC5168]. o Companies have been using INFO messages in order to transport DTMF tones. All mechanisms are proprietary, and have not been standardized. Some legacy INFO usages are also recognized as being shortcuts to more appropriate and flexible mechanisms. Furthermore, RFC 2976 did not define mechanisms that would enable a SIP UAcan onlyto indicatea set(1) the types ofInfo Packages forapplications and contexts in whichit is willing to receive INFO requests by usingthey support theSIP methods (and their responses) listed in Section 4. A UA MUST NOT send anINFOrequest outside an invite dialog usagemethod or (2) the types of application andMUST NOT send ancontext with which a specific INFOrequest for anmessage is associated. Because legacy INFO usages do not have associated InfoPackage inside an invite dialog usage if the remote UA hasPackages, it is notindicated willingnesspossible toreceive thatuse the Recv-Info and Info-Packagewithin that dialog. If a UA receives a 469 (Bad Info Package) response to anheader fields with legacy INFOrequest, based on [RFC5057] the response representsusages. That is, aTransaction Only failure, and theUAMUST NOT terminatecannot use theinvite dialog usage. DueRecv-Info header field tothe possibility of forking, the UAindicate for whichsends the initial INVITE request MUST be preparedlegacy INFO usages it is willing to receive INFOrequests from multiple remote UAs during the early dialog phase. In addition, therequests, and a UAMUST be prepared to receive different Recv-Infocannot use the Info-Package header fieldvalues from different remote UAs. NOTE: If the UAS (receiver of the initial INVITE request) sendsto indicate for which legacy INFO usage an INFO requestjust after it has sent the response which creates the dialog, the UAS needsis associated with. Due tobe prepared thatthe problems described above, legacy INFOrequest can reach the UAC before the dialog creating response,usages often require static configuration about for what type of applications andmight therefore be rejected bycontexts UAs support theUAC. In addition, anINFOrequest might be rejected due to a race condition, if a UA sendsmethod, and the way they handle application information transported in INFOrequest atmessages. That has caused interoperability problems in thesame time asindustry. To overcome these problems, theremote UA sends a new set of Info Packages for whichSIP Working Group has spent significant discussion time over many years coming to agreement on whether itis willingwas more appropriate toreceive INFO requests. 3.2.2. INFO Request Receiver If a UA receives anfix INFOrequest associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 (Bad Info Package) response (see Section 11.6), which contains(by defining aRecv-Info header field with Info Packagesregistration mechanism forwhichtheUA is willingways in which it was used) or toreceive INFO requests. The UA MUST NOT usedeprecate it altogether (with theresponse to updateusage described in RFC 3398 [RFC3398] being grandfathered as theset of Info Packages, but simplysole legitimate usage). Although it required substantial consensus building and concessions by those more inclined toindicatecompletely deprecate INFO, thecurrent set. Ineventual direction of theterminologyworking group was to publish a framework for registration ofMultiple Dialog Usages [RFC5057],INFO packages as defined in thisrepresents a Transaction Only failure,specification. 3. Applicability anddoes not terminate the invite dialog usage. IfBackward Compatibility This document defines aUA receives an INFO request associated withmethod, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Packageandmechanism. The document obsoletes RFC 2976 [RFC2976]. For backward compatibility, themessage body part with Content-Disposition 'Info-Package' (see Section 3.3.1) hasdocument also specifies aMultipurpose Internet Mail Extensions (MIME) type that the UA supports but not in the context"legacy" mode of usage of the INFO method thatInfo Package, itisRECOMMENDED that the UA send a 415 (Unsupported Media Type) response. The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx), in accordancecompatible with theerror handling proceduresusage previously defined in[RFC3261]. Otherwise, if theRFC 2976, referred to as "legacy INFOrequest is syntactically correctUsage". For backward compatibility purposes, this document does not deprecate legacy INFO usages, andwell structured, thedoes not mandate users to define Info Packages for such usages. However: 1. A UA MUSTsendNOT insert an Info-Package header field in a200 (OK) response. NOTE: If the application needs to reject the information which it receivedlegacy INFO request (as described in Section 3, an INFOrequest, that needs to be done on the application level. I.e. the application needs to trigger a new INFO request, whichrequest associated with an Info Package always containsinformationan Info-Package header field). 2. It is strongly RECOMMENDED that any new usage uses thepreviously received application data was not accepted. IndividualInfo Packagespecifications need to describemechanism defined in this specification, since it does not share thedetails for such procedures. 3.2.3. SIP Proxies Proxies need no additional behavior beyond that described in [RFC3261] to support INFO. 3.3.issues associated with legacy INFOMessage Body 3.3.1.usage, and since Info Packages can be registered with IANA. 3. UAs are allowed to enable both legacy INFORequest Message Body The purposeusages and Info Package usages as part of the same invite dialog usage, but UAs SHALL NOT mix legacy INFOrequest isusages and Info Package usages in order tocarrytransport the same application levelinformation between SIP UAs.information. If possible, UAs SHALL prefer the usage of an Info Package. 4. The INFO Method 4.1. General The INFO method provides a mechanism for transporting application level informationdata is carried inthat can further enhance a SIP application. Annex A gives more details on thepayloadtypes of applications for which themessage bodyuse of INFO is appropriate. This section describes how a UA handles INFO requests and responses, as well as the message bodies included in INFOrequest. NOTE:messages. 4.2. INFO Request 4.2.1. INFO Request Sender An INFO request can be associated with an Info Packagecan also include information(see Section 5), or associated with a legacy INFO usage (see Section 2). The construction of theInfo Package using Info- Package header field parameters. IfINFO request is the same as any other non- target refresh request within an existing invite dialog usage as described in Section 12.2 of RFC 3261. When a UA sends an INFO request associated with an InfoPackage contains a message body part, the body part is identified by a Content-DispositionPackage, it MUST include an Info-Package header field'Info-Package' value. The body part can contain a single MIME type, or it can be a multipart [RFC5621]that indicates whichcontains other body partsInfo Package is associated with the request. A specific INFO request can be used only for a single Info Package.UAs MUST support multipart body parts in accordance with [RFC5621]. NOTE: AnWhen a UA sends an INFO requestcan also contain other body parts that are meaningful within the context ofassociated with aninvite dialoglegacy INFO usagebut are not specificallythere is no Info Package associated with theINFO methodrequest, and theapplication concerned. When a UA supports a specific Info-Package, theUA MUSTalso support message body MIME types in accordance with that Info-Package. However,NOT include an Info-Package header field inaccordance with [RFC3261]the request. The INFO request MUST NOT contain a Recv-Info header field. A UAstill indicates the supported MIME typescan only indicate a set of Info Packages for which it is willing to receive INFO requests by using theAccept header. 3.3.2. INFO Response Message BodySIP methods (and their responses) listed in Section 5. A UA MUST NOTinclude a message body associated with an Info Package insend an INFOresponse. Message bodies associated with Info Packagesrequest outside an invite dialog usage and MUSTonly be sent inNOT send an INFOrequests. A UA MAY include a message body which is not associated withrequest for an Info Packageininside anINFO response. 3.4. Order of Delivery The Info Package mechanism doesinvite dialog usage if the remote UA has notdefineindicated willingness to receive that Info-Package within that dialog. If adelivery order mechanism.UA receives a 469 (Bad InfoPackages can rely on the CSeq header fieldPackage) response todetect ifan INFOrequest is received out of order. If specific applications need additional mechanisms for order of delivery, those mechanisms,request, based on RFC 5057 the response represents a Transaction Only failure, andrelated procedures, are specified as part oftheassociated Info Package (e.g.UA MUST NOT terminate theuseinvite dialog usage. Due to the possibility ofsequence numbers withinforking, theapplication data). 4. Info Packages 4.1. General An Info Package specification definesUA which sends thecontent and semanticsinitial INVITE request MUST be prepared to receive INFO requests from multiple remote UAs during the early dialog phase. In addition, the UA MUST be prepared to receive different Recv-Info header field values from different remote UAs. NOTE: If the UAS (receiver of theinformation carried ininitial INVITE request) sends an INFOmessage associated with an Info Package. The Info Package mechanism provides a way for UAs to indicate forrequest just after it has sent the response whichInfo Packages they are willingcreates the dialog, the UAS needs toreceivebe prepared that the INFOrequests,request can reach the UAC before the dialog creating response, andwhich Info Package a specificmight therefore be rejected by the UAC. In addition, an INFO requestis associated with. 4.2. User Agent Behavior 4.2.1. General This section describes howmight be rejected due to aUA handles Info Packages, howrace condition, if a UAuses the Recv-Info header field, and how the UA acts in re-INVITE rollback situations. 4.2.2. UA Procedures A UA which supportssends theInfo Package mechanism MUST indicate, usingINFO request at theRecv-Info header field,same time as the remote UA sends a new set of Info Packages for which it is willing to receive INFOrequests forrequests. 4.2.2. INFO Request Receiver If aspecific session. AUAcan list multiplereceives an INFO request associated with an InfoPackages in a single Recv-Info header field, andPackage that the UAcan use multiple Recv-Info header fields. Ahas not indicated willingness to receive, the UAcan use an empty Recv-Info header field, i.e.MUST send a 469 (Bad Info Package) response (see Section 11.6), which contains a Recv-Info header fieldwithout any header field values. A UA provides its set ofwith Info Packages for whichitthe UA is willing to receive INFOrequests during the dialog establishment. Arequests. The UAcanMUST NOT use the response to update the set of InfoPackages duringPackages, but simply to indicate the current set. In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure, and does not terminate the invite dialog usage. If a UAis not willing to receivereceives an INFOrequests for any Info Packages, during dialog establishment or later during the invite dialog usage, the UA MUST indicate this by includingrequest associated with anempty Recv-Infoheader field. This informs other UAsPackage and the message body part with Content-Disposition 'Info-Package' (see Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) type that the UAstillsupports but not in the context of that InfoPackage mechanism. Example: IfPackage, it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response. The UAhas previously indicated Info Packages 'foo'MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx) and'bar'Global Failure (6xx), ina Recv-Info header field,accordance with the error handling procedures defined in RFC 3261. Otherwise, if the INFO request is syntactically correct and well structured, the UAduringMUST send a 200 (OK) response. NOTE: If thelifetime of the invite dialog usage wants to indicate that it does not wantapplication needs toreceive INFO requests for any Info Packages anymore,reject theUA sends a message withinformation which it received in anempty Recv-Info header field. Once a UA has sent a message with a Recv-Info header field containing a set of Info Packages,INFO request, that needs to be done on theset is valid untilapplication level. I.e. theUA sendsapplication needs to trigger a newRecv-Info header field containing a new, or empty, set ofINFO request, which contains information that the previously received application data was not accepted. Individual InfoPackages. Once a UA has indicatedPackage specifications need to describe the details for such procedures. 4.2.3. SIP Proxies Proxies need no additional behavior beyond thatit is willingdescribed in RFC 3261 toreceivesupport INFO. 4.3. INFOrequests for a specific Info Package, and a dialog has been established,Message Body 4.3.1. INFO Request Message Body The purpose of theUA MUST be preparedINFO request is toreceivecarry application level information between SIP UAs. The application information data is carried in the payload of the message body of the INFO request. NOTE: An INFO request associated withthatan Info Packageuntil the UA indicates that it is no longer willing to receive INFO requestscan also include information associated withthatthe InfoPackage. For a specific dialog usage, a UA MUST NOT sendPackage using Info- Package header field parameters. If an INFO request associated with an Info Packageuntil it has received an indication thatcontains a message body part, theremote UAbody part iswilling to receive INFO requests for that Info Package, or after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package. NOTE: When a UA sends a message which containsidentified by aRecv-InfoContent-Disposition header fieldwith'Info-Package' value. The body part can contain anew set of Info Packages for which the UA is willing to receive INFO requests the remote UA might, beforesingle MIME type, or itreceivescan be a multipart [RFC5621] which contains other body parts associated with themessage, send anInfo Package. UAs MUST support multipart body parts in accordance with RFC 5621. NOTE: An INFO requestbased on the old set of Info Packages. In this casecan also contain other body parts that are meaningful within thereceivercontext of an invite dialog usage but are not specifically associated with the INFOrequests rejects,method andsends a 469 (Bad Info Package) response to,theINFO request. Ifapplication concerned. When a UAindicates multiple Info Packages, which provide similar functionality, it is not possible to indicatesupports apriority order ofspecific Info-Package, theInfo Packages, or to indicateUA MUST also support message body MIME types in accordance with that Info-Package. However, in accordance with RFC 3261 the UAwishes to only receive INFO requests for one ofstill indicates theInfo Packages. It is up tosupported MIME types using theapplication logicAccept header. 4.3.2. INFO Response Message Body A UA MUST NOT include a message body associated withthe Info Packages, and specifican Info Packagespecifications, to describe application behaviorinsuch cases. For backward compatibility purpose, even if a UA indicates support of thean INFO response. Message bodies associated with InfoPackage mechanism, it is still allowed to enable legacyPackages MUST only be sent in INFOusages Section 9. In addition, if arequests. A UAindicates support of the INFO method using the Allow header field [RFC3261], it doesMAY include a message body which is notimplicitly indicate support of theassociated with an Info Packagemechanism. A UA MUST use the Recv-Info header fieldinorder to indicate that it supports thean INFO response. 4.4. Order of Delivery The Info Packagemechanism. Likewise, even ifmechanism does not define aUA usesdelivery order mechanism. Info Packages can rely on theRecv-InfoCSeq header field toindicate that it supportsdetect if an INFO request is received out of order. If specific applications need additional mechanisms for order of delivery, those mechanisms, and related procedures, are specified as part of the associated Info Packagemechanism, in addition(e.g. theUA still indicates supportuse of sequence numbers within theINFO method using the Allow header. This document does not define a SIP option tag [RFC3261] for theapplication data). 5. InfoPackage mechanism. However, anPackages 5.1. General An Info Package specificationcan definedefines the content and semantics of the information carried in anoption-tagINFO message associated withthe specifican InfoPackage, as described in Section 10.6. 4.2.3. Recv-Info header field rulesPackage. Thetext below defines rules on whenInfo Package mechanism provides aUA is requiredway for UAs toinclude a Recv-Info header field in SIP messages. Section 6.1 lists the SIP methods,indicate for which Info Packages they are willing to receive INFO requests, and which Info Package aUA can insertspecific INFO request is associated with. 5.2. User Agent Behavior 5.2.1. General This section describes how a UA handles Info Packages, how a UA uses the Recv-Info headerfield in requestsfield, andresponses. - The sender of an initial INVITE requesthow the UA acts in re-INVITE rollback situations. 5.2.2. UA Procedures A UA which supports the Info Package mechanism MUSTinclude aindicate, using the Recv-Info headerfield in the initial INVITE request, even iffield, thesenderset of Info Packages for which it isnotwilling to receive INFO requestsassociated with any Info Package. - The receiver of a request which contains a Recv-Info header field MUST includefor aRecv-Info header fieldspecific session. A UA can list multiple Info Packages in areliable 18x/2xx response to the request, even if the request contains an emptysingle Recv-Info header field, andeven if the header field value of the receiver has not changed sincetheprevious time it sent aUA can use multiple Recv-Info headerfield. -fields. A UAMUST NOT include acan use an empty Recv-Info headerfield in a response if the associated request did not containfield, i.e. aRecv-Infoheaderfield. NOTE: Different from the rules for generating SDP answers [RFC3264], the receiver of a request which contains afield without any header field values. A UA provides its set of Info Packages for which it isnot restrictedwilling togenerate its ownreceive INFO requests during the dialog establishment. A UA can update the set of Info Packagesas a subset ofduring the invite dialog usage. If a UA is not willing to receive INFO requests for any InfoPackage set received inPackages, during dialog establishment or later during theInfo Package header field of the request. Similar to SDP answers, the receiver can include the same Recv-Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, butinvite dialog usage, thereceiverUA MUSTuse the same Recv-Infoindicate this by including an empty Recv- Info headerfield value (if included) in all responses forfield. This informs other UAs that the UA still supports thesame transaction. 4.2.4.Info Packagefallback rulesmechanism. Example: Ifthe receiver ofarequest which containsUA has previously indicated Info Packages 'foo' and 'bar' in a Recv-Info headerfield rejectsfield, and therequest, bothUA during thesender and receiverlifetime of therequest MUST roll backinvite dialog usage wants tothe set ofindicate that it does not want to receive INFO requests for any Info Packageswhich was used before the request was sent. This also applies to the case whereanymore, thereceiver ofUA sends a message with anINVITE/re-INVITE requestempty Recv-Info header field. Once a UA hasincludedsent a message with a Recv-Info header fieldincontaining aprovisional response, but later rejects the request. NOTE: The dialog state rollback rules forset of InfoPackages might differ fromPackages, the set is valid until therules for other types of dialog state information (SDP, target, etc). 4.3. REGISTER Processing This document allows aUAto insertsends a new Recv-Info header fieldincontaining aREGISTER request. However,new, or empty, set of Info Packages. Once a UASHALL NOT include a header valuehas indicated that it is willing to receive INFO requests for a specific InfoPackage unless the specific Info Package specification describes how the header field value shall be interpretedPackage, andused by the registrar, e.g. in ordera dialog has been established, the UA MUST be prepared todeterminereceive INFO requesttargets. Rather than usingassociated with that Info Package until theRecv-Info header field in orderUA indicates that it is no longer willing todeterminereceive INFO requests associated with that Info Package. For a specific dialog usage, a UA MUST NOT send an INFO requesttargets,associated with an Info Package until it has received an indication that the remote UA isrecommendedwilling touse more appropriate mechanisms, e.g.receive INFO requests for that Info Package, or after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package. NOTE: When a UA sends a message which contains a Recv-Info header field with a new set of Info Packages for which the UA is willing to receive INFO requests the remote UA might, before it receives the message, send an INFO request based on[RFC3840]. However,the old set of Info Packages. In thisdocument doescase the receiver of the INFO requests rejects, and sends a 469 (Bad Info Package) response to, the INFO request. If a UA indicates multiple Info Packages, which provide similar functionality, it is notdefinepossible to indicate afeature tag forpriority order of the InfoPackage mechanism,Packages, ora mechanismtodefine feature tags for specific Info Packages. 5. Formal INFO Method Definition 5.1.indicate that the UA wishes to only receive INFOMethod This document describesrequests for onenew SIP method: INFO. This document replacesof thedefinition and registrations found in [RFC2976]. This table expands on Tables 2Info Packages. It is up to the application logic associated with the Info Packages, and3specific Info Package specifications, to describe application behavior in[RFC3261]. Header Wheresuch cases. For backward compatibility purpose, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO------ ----- ---- Accept R o Accept 415 o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415 o Accept-Resource-Priority 2xx,417 o Alert-Info - Allow R o Allow 405 m Allow r o Authentication-Info 2xx o Authorization R o Call-ID c m Call-Info o Contact - Content-Disposition o Content-Encoding o Content-Language o Content-Length o Content-Type * CSeq c m Date o Error-Info 3xx-6xx o Expires - From c m Geolocation R o Geolocation-Error r o Max-Breadth R - Max-Forwards R o MIME-Version o Min-Expires - Organization - Priority R - Privacy o Proxy-Authenticate 401 o Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx,18x o Referred-By R o Request-Disposition R o Require o Resource-Priority o Retry-After R - Retry-After 404,413,480,486 o Retry-After 500,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 o To c m (w/ Tag) Unsupported 420 o User-Agent o Via m Warning r o WWW-Authenticate 401 m WWW-Authenticate 407 o Figure 1: Table 1: Summaryusages. In addition, if a UA indicates support ofHeader Fields 6.the INFOHeader Fields 6.1. General This table expands on tables 2 and 3 in [RFC3261]. Headermethod using the Allow header fieldwhere proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD ------------------------------------------------------------------ Info-Package R - - - - - - - m* - - Recv-Info R - - - m - o o - - o Recv-Info 2xx - - - o** - - o***- - o***[RFC3261], it does not implicitly indicate support of the Info Package mechanism. A UA MUST use the Recv-Info1xx - - - o** - - - - - -header field in order to indicate that it supports the Info Package mechanism. Likewise, even if a UA uses the Recv-Info469 - - - - - - - m* - -header field to indicate that it supports the Info Package mechanism, in addition the UA still indicates support of the INFO method using the Allow header. This document does not define a SIP option tag [RFC3261] for the Info Package mechanism. However, an Info Package specification can define an option-tag associated with the specific Info Package, as described in Section 10.6. 5.2.3. Recv-Infor - - - o - - o - - o Headerheader fieldwhere SUB NOT RFR -------------------------------- Info-Package R - - - Recv-Info R - - - Recv-Info 2xx - - - Recv-Info 1xx - - -rules The text below defines rules on when a UA is required to include a Recv-Info469 - - -header field in SIP messages. Section 7.1 lists the SIP methods, for which a UA can insert a Recv-Infor - -header field in requests and responses. -Table 2: INFO-related Header FieldsThesupport and usagesender ofthe Info-Package andan initial INVITE request MUST include a Recv-Info headerfieldsfield in the initial INVITE request, even if the sender is notapplicable to UAs that only support legacy INFO usages. * Not applicablewilling to receive INFO requestsand responsesassociated withlegacy INFO usages. ** Mandatoryany Info Package. - The receiver of a request which contains a Recv-Info header field MUST include a Recv-Info header field inat least onea reliable 18x/2xxresponse, if sent,response to theINVITErequest, even if theassociated INVITErequestcontainedcontains an empty Recv-Info header field, and even if the header field value of the receiver has not changed since the previous time it sent a Recv-Info header field.*** Mandatory- A UA MUST NOT include a Recv-Info header field in a response if the associated requestcontaineddid not contain a Recv-Info header field.As defined in section 20NOTE: Different from the rules for generating SDP answers [RFC3264], the receiver ofRFC 3261 [RFC3261],a"mandatory" header field MUST be present inrequest which contains a set of Info Packages is not restricted to generate its own set of Info Packages as arequest, and MUST be understood bysubset of theUAS receivingInfo Package set received in therequest." 6.2. Info-PackageInfo Package header fieldThis document adds Info-Packageof the request. Similar to SDP answers, thedefinition ofreceiver can include theelement "message-header"same Recv-Info header field value in multiple responses (18x/2xx) for theSIP message grammar [RFC3261]. Section 3 describessame INVITE/re-INVITE transaction, but theInfo-Packagereceiver MUST use the same Recv-Info header fieldusage. Forvalue (if included) in all responses for thepurposes of matchingsame transaction. 5.2.4. Info Packagetypes indicated in Recv- Info with those infallback rules If theInfo-Packagereceiver of a request which contains a Recv-Info header fieldvalue, one comparesrejects theInfo-package-name portionrequest, both the sender and receiver of theInfo-package-type portionrequest MUST roll back to the set of Info Packages which was used before theInfo-Packagerequest was sent. This also applies to the case where the receiver of an INVITE/re-INVITE request has included a Recv-Info header fieldoctet-by-octet with that ofin a provisional response, but later rejects the request. NOTE: The dialog state rollback rules for Info Packages might differ from the rules for other types of dialog state information (SDP, target, etc). 5.3. REGISTER Processing This document allows a UA to insert a Recv-Info header fieldvalue. That is,in a REGISTER request. However, a UA SHALL NOT include a header value for a specific Info Package unless the specific Info Packagename is case sensitive. Info-package-param is not part ofspecification describes how the header field value shall be interpreted and used by the registrar, e.g. in order to determine request targets. Rather than using thecomparison-checking algorithm. ThisRecv-Info header field in order to determine request targets, it is recommended to use more appropriate mechanisms, e.g. based on RFC 3840 [RFC3840]. However, this document does not definevaluesa feature tag forInfo-Package types. Individualthe Info Packagespecificationsmechanism, or a mechanism to definethese values. 6.3. Recv-Info header fieldfeature tags for specific Info Packages. 6. Formal INFO Method Definition 6.1. INFO Method This documentadds Recv-Info todescribes one new SIP method: INFO. This document replaces the definition and registrations found in RFC 2976 [RFC2976]. This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. Header Where INFO ------ ----- ---- Accept R o Accept 415 o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415 o Accept-Resource-Priority 2xx,417 o Alert-Info - Allow R o Allow 405 m Allow r o Authentication-Info 2xx o Authorization R o Call-ID c m Call-Info o Contact - Content-Disposition o Content-Encoding o Content-Language o Content-Length o Content-Type * CSeq c m Date o Error-Info 3xx-6xx o Expires - From c m Geolocation R o Geolocation-Error r o Max-Breadth R - Max-Forwards R o MIME-Version o Min-Expires - Organization - Priority R - Privacy o Proxy-Authenticate 401 o Proxy-Authenticate 407 m Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx,18x o Referred-By R o Request-Disposition R o Require o Resource-Priority o Retry-After R - Retry-After 404,413,480,486 o Retry-After 500,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 o To c m (w/ Tag) Unsupported 420 o User-Agent o Via m Warning r o WWW-Authenticate 401 m WWW-Authenticate 407 o Figure 1: Table 1: Summary ofthe element "message-header" in the SIP message grammar [RFC3261]. Section 4 describes the Recv-Info header field usage.Header Fields 7.Info Package ConsiderationsINFO Header Fields 7.1. General Thissection covers considerations to take into account when deciding whether the usage of an Info Package is appropriate for transporting of application information for a specific use-case. 7.2. Appropriateness of Info Package Usage When designing an Info Package, for application level information exchange, it is important to consider: is signaling, using INFO requests, within a SIP dialog, an appropriate mechanism for the use- case? Is it because it is the most reasonabletable expands on tables 2 andappropriate choice, or merely because "it's easy"? Choosing an inappropriate mechanism for a specific use-case can cause negative effects3 inSIP networksRFC 3261 [RFC3261]. Header field wherethe mechanism is used. 7.3. Alternative Mechanisms 7.3.1. Alternative SIP signaling plane mechanisms 7.3.1.1. General This subsection describes some alternative mechanisms for transporting application information on the SIP signaling plane, using SIP messages. 7.3.1.2. INFO Request Rateproxy ACK BYE CAN INV OPT REG PRA INF MSG UPD ------------------------------------------------------------------ Info-Package R - - - - - - - m* - - Recv-Info R - - - m - o o - - o Recv-Info 2xx - - - o** - - o***- - o*** Recv-Info 1xx - - - o** - - - - - - Recv-Info 469 - - - - - - - m* - - Recv-Info r - - - o - - o - - o Header field where SUB NOT RFR -------------------------------- Info-Package R - - - Recv-Info R - - - Recv-Info 2xx - - - Recv-Info 1xx - - - Recv-Info 469 - - - Recv-Info r - - - Table 2: INFO-related Header Fields The support andVolume INFO messages differ from many other sortsusage ofSIP messages in that they carry application information, andthesizeInfo-Package andrate of the INFO messageRecv-Info header fields isdirectly determined by the application. This can cause application information trafficnot applicable tointerfere with other traffic onUAs thatinfrastructure, oronly support legacy INFO usages. * Not applicable toself-interfere when data rates become too high. There is no default throttling mechanism forINFOrequests. Apart fromrequests and responses associated with legacy INFO usages. ** Mandatory in at least one reliable 18x/2xx response, if sent, to theSIP session establishment,INVITE request, if thenumber of SIP messages exchanged duringassociated INVITE request contained a Recv-Info header field. *** Mandatory if thelifetimeassociated request contained anormal SIP session is rather small. Some applications, like sendingRecv-Info header field. As defined in section 20 ofDual-Tone Multi-Frequency (DTMF) tones, can generateRFC 3261, aburst of up to 20 messages per second. Other applications, like constant GPS location updates, could generate"mandatory" header field MUST be present in ahigh rate of INFO requests duringrequest, and MUST be understood by the UAS receiving thelifetimerequest." 7.2. Info-Package header field This document adds Info-Package to the definition of theinvite dialogelement "message-header" in the SIP message grammar [RFC3261]. Section 4 describes the Info-Package header field usage.A designerFor the purposes ofanmatching InfoPackage, andPackage types indicated in Recv- Info with those in theapplication that uses it, need to considerInfo-Package header field value, one compares theimpact thatInfo-package-name portion of thesize andInfo-package-type portion of therateInfo-Package header field octet-by-octet with that of theINFO messages have onRecv-Info header field value. That is, thenetwork and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO messageInfo Package name issent over such a transport protocol, a downstream SIP entity might forwardcase sensitive. Info-package-param is not part of themessage over a transport protocol thatcomparison-checking algorithm. This document does notprovide congestion control. Furthermore, SIP messages tend to be relatively small, on the order of 500 Bytes to 32K Bytes. SIP is a poor mechanismdefine values fordirect exchange of bulk data beyondInfo-Package types. Individual Info Package specifications define theselimits, especially if the headers plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. Appropriate mechanisms for such traffic include the Hypertext Transfer Protocol (HTTP) [RFC2616], the Message Session Relay Protocol (MSRP) [RFC4975], or other media plane data transport mechanisms. RFC 5405 [RFC5405] provides additional guidelines for applications using UDP that may be useful background reading. 7.3.1.3. SUBSCRIBE/NOTIFY An alternative for application level interaction isvalues. 7.3. Recv-Info header field This document adds Recv-Info touse subscription-based events [RFC3265], which usesthe definition of the element "message-header" in the SIPSUBSCRIBE and NOTIFY methods. Using that mechanism, a UA requests state information, such as key pad presses from a device to an application server or key map images from an application servermessage grammar [RFC3261]. Section 5 describes the Recv-Info header field usage. 8. Info Package Considerations 8.1. General This section covers considerations toa device. Event Packages [RFC3265] performtake into account when deciding whether theroleusage ofdisambiguating the contextan Info Package is appropriate for transporting ofa messageapplication information forsubscription-based events. Thea specific use-case. 8.2. Appropriateness of Info Packagemechanism provides similar functionalityUsage When designing an Info Package, for application level informationexchangeexchange, it is important to consider: is signaling, usinginvite dialog usages [RFC5057]. While anINFOrequest is always part of, and shares the fate of, an existing invite dialog usage, a SUBSCRIBE request createsrequests, within aseparate dialog usage [RFC5057], and is normally sent outsideSIP dialog, anexisting dialog usage. The subscription-basedappropriate mechanismcan be used by SIP entities to receive state information about SIP dialogs and sessions, without requiringfor theentities to be part ofuse- case? Is it because it is theroute set of those dialogs and sessions. As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxiesmost reasonable andB2BUAs, the resource impact caused by the subscription dialogs needs to be considered. The number of subscription dialogs per user also needs to be considered. Asappropriate choice, or merely because "it's easy"? Choosing an inappropriate mechanism forany othera specific use-case can cause negative effects in SIP networks where the mechanism is used. 8.3. Alternative Mechanisms 8.3.1. Alternative SIP signaling planebased mechanismmechanisms 8.3.1.1. General This subsection describes some alternative mechanisms for transporting applicationinformation,information on theSUBSCRIBE/NOTIFYSIP signaling plane, using SIP messages. 8.3.1.2. INFO Request Rate and Volume INFO messagescan put a significant burden on intermediatediffer from many other sorts of SIPentities which are partmessages in that they carry application information, and the size and rate of thedialog route set, but do not have any interest inINFO message is directly determined by the application. This can cause application informationtransported between the end users. 7.3.1.4. MESSAGE The MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for renderingtraffic tothe user. 7.3.2. Media Plane Mechanisms 7.3.2.1. General In SIP, media plane channels associatedinterfere with other traffic on that infrastructure, or to self-interfere when data rates become too high. There is no default throttling mechanism for INFO requests. Apart from the SIPdialogs are established using SIP signaling, butsession establishment, thedatanumber of SIP messages exchangedonduring themedia plane channel does not traverselifetime a normal SIPsignaling intermediates, so if there will besession is rather small. Some applications, like sending of Dual-Tone Multi-Frequency (DTMF) tones, can generate alotburst ofinformation exchanged,up to 20 messages per second. Other applications, like constant GPS location updates, could generate a high rate of INFO requests during the lifetime of the invite dialog usage. A designer of an Info Package, and the application that uses it, need to consider the impact that the size andthere is no need fortheSIP signaling intermediaries to examinerate of theinformation,INFO messages have on the network and on other traffic, since it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. Even if an INFO message isrecommended to usesent over such amedia plane mechanism, rather thantransport protocol, a downstream SIPsignaling based. A low latency requirement forentity might forward theexchange of information is one strong indicator for usingmessage over amedia channel. Exchanging information through thetransport protocol that does not provide congestion control. Furthermore, SIProuting network can introduce hundreds of millisecondsmessages tend to be relatively small, on the order oflatency. 7.3.2.2. MRCP One500 Bytes to 32K Bytes. SIP is a poor mechanism formedia planedirect exchange ofapplicationbulk dataisbeyond these limits, especially if theMedia Resource Controlheaders plus body exceed the User Datagram Protocol(MRCP) [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented channel,(UDP) MTU [RFC0768]. Appropriate mechanisms for suchas a Transmission Controltraffic include the Hypertext Transfer Protocol(TCP) [RFC0793] or Stream Control Transmission(HTTP) [RFC2616], the Message Session Relay Protocol(SCTP) [RFC4960] stream is established. 7.3.2.3. MRSP MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and(MSRP) [RFC4975], or othersuch large-volume uses. 7.3.3. Non-SIP related mechanisms Anothermedia plane data transport mechanisms. RFC 5405 [RFC5405] provides additional guidelines for applications using UDP that may be useful background reading. 8.3.1.3. SUBSCRIBE/NOTIFY An alternative for application level interaction is to usea SIP-independentsubscription-based events [RFC3265], which uses the SIP SUBSCRIBE and NOTIFY methods. Using that mechanism, a UA requests state information, such asHTTP [RFC2616]. In this model, the UA knows aboutkey pad presses from arendezvous pointdevice todirect HTTP requestsan application server or key map images from an application server tofor the transfer of information. Examples include encoding ofaprompt to retrieve indevice. Event Packages [RFC3265] perform theSIP Request URI in [RFC4240] orrole of disambiguating theencodingcontext of aSUBMIT target in a VoiceXML [W3C.REC- voicexml21-20070619] script. 8. Syntax 8.1. General This section describes the syntax extensions to the ABNF syntax defined in [RFC3261] requiredmessage forthesubscription-based events. The Info Package mechanism provides similar functionality for application information exchange using invite dialog usages [RFC5057]. While an INFOmethod,request is always part of, andadds definitions forshares theInfo-Packagefate of, an existing invite dialog usage, a SUBSCRIBE request creates a separate dialog usage [RFC5057], andRecv-Info header fields.is normally sent outside an existing dialog usage. Theprevious sections describesubscription-based mechanism can be used by SIP entities to receive state information about SIP dialogs and sessions, without requiring thesemantics. The ABNF defined in this specification is conformantentities to[RFC5234]. 8.2. ABNF INFOm = %x49.4E.46.4F ; INFO in caps Method =/ INFOm message-header =/ (Info-Package / Recv-Info) CRLF Info-Package = "Info-Package" HCOLON Info-package-type Recv-Info = "Recv-Info" HCOLON [Info-package-list] Info-package-list = Info-package-type *( COMMA Info-package-type ) Info-package-type = Info-package-name *( SEMI Info-package-param) Info-package-name = token Info-package-param = generic-param 9. Legacy INFO Usage 9.1. General A numberbe part ofapplications, standardized and proprietary, make usethe route set of those dialogs and sessions. As SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies and B2BUAs, theINFO method as it was previously defined in [RFC2976], referredresource impact caused by the subscription dialogs needs toas "legacy INFO usage". For backward compatibility purpose, this document does not deprecate such usages, and does not mandate usersbe considered. The number of subscription dialogs per user also needs todefine Info Packagesbe considered. As forsuch usages. However, it is strongly RECOMMENDED thatanynew usage uses the Info Packageother SIP signaling plane based mechanismdefined in this specification, since it does not share the issues associated with legacy INFO usage, and since Info Packages can be registered with IANA. 9.2. Problems While legacy INFO usage has been widely adoptedforspecifictransporting applicationuse cases, [RFC2976] did not defineinformation, the SUBSCRIBE/NOTIFY messages can put amechanism forsignificant burden on intermediate SIPUAs to indicate forentities whichtypesare part ofapplications and contexts they supporttheINFO method. In addition, [RFC2976] diddialog route set, but do notprovide a mechanism to explicitly indicatehave any interest in thetype ofapplicationand context for which a specific INFO message is associated. Example: If the Content-Type is "image/jpeg",information transported between theMIME-attached content is a JPEG image. Still, there are many useful ways a UA can render an image.end users. 8.3.1.4. MESSAGE Theimage could be a caller-id picture, a contact icon, a photoMESSAGE method [RFC3428] defines one-time instant message exchange, typically forsharing, and so on. The sender does not know which image to sendsending MIME contents for rendering to thereceiver ifuser. 8.3.2. Media Plane Mechanisms 8.3.2.1. General In SIP, media plane channels associated with SIP dialogs are established using SIP signaling, but thereceiver supports an image content type. Likewise,data exchanged on thereceivermedia plane channel does notknow the contexttraverse SIP signaling intermediates, so if there will be a lot ofan image the clientinformation exchanged, and there issending ifno need for thereceiver supports receiving more than one image content type. Since legacy INFO usages do not have associated Info Packages, it is not possibleSIP signaling intermediaries touse the Recv-Info and Info-Package header fields with legacy INFO usages. That is, a UA cannot useexamine theRecv-Info header field to indicate for which legacy INFO usagesinformation, it iswillingrecommended toreceive INFO requests, and a UA cannotusethe Info-Package header field to indicatea media plane mechanism, rather than a SIP signaling based. A low latency requirement forwhich legacy INFO usage an INFO requestthe exchange of information isassociated with. Due toone strong indicator for using a media channel. Exchanging information through theproblems described above, legacy INFO usages often require static configuration aboutSIP routing network can introduce hundreds of milliseconds of latency. 8.3.2.2. MRCP One mechanism forwhat typemedia plane exchange ofapplications and contexts UAs supportapplication data is theINFO method,Media Resource Control Protocol (MRCP) [I-D.ietf-speechsc-mrcpv2], where a media plane connection-oriented channel, such as a Transmission Control Protocol (TCP) [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] stream is established. 8.3.2.3. MRSP MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses. 8.3.3. Non-SIP related mechanisms Another alternative is to use a SIP-independent mechanism, such as HTTP [RFC2616]. In this model, theway they handle application information transported in INFO messages. That has caused interoperability problems in the industry. Therefore,UA knows about aneedrendezvous point to direct HTTP requests to fora well defined and documented description of whattheinformation senttransfer of information. Examples include encoding of a prompt to retrieve in theINFO is used for has been identified. This situation is analogous toSIP Request URI in [RFC4240] or thecontext issueencoding of a SUBMIT target inInternet Mail [RFC3458]. Section 4.1a VoiceXML [W3C.REC- voicexml21-20070619] script. 9. Syntax 9.1. General This section describeshowtheInfo Package mechanisms solvessyntax extensions to theissues associated with legacy INFO usages. 9.3. Co-existence with Info Package based INFO usage As described in Section 3, an INFO request associated with an Info Package always contains an Info-Package header field. A UA MUST NOT insert an Info-Package header fieldABNF syntax defined ina legacy INFO request. UAs are allowed to enable both legacyRFC 3261 required for the INFOusagesmethod, andInfo Package usages as part ofadds definitions for thesame invite dialog usage. However, UAs SHALL NOT mix legacy INFO usagesInfo-Package andInfo Package usagesRecv-Info header fields. The previous sections describe the semantics. The ABNF defined inorderthis specification is conformant totransport the same application level information. If possible, UAs SHALL prefer the usage of an Info Package. See Appendix A for examples of existing legacyRFC 5234 [RFC5234]. 9.2. ABNF INFOm = %x49.4E.46.4F ; INFOusages.in caps Method =/ INFOm message-header =/ (Info-Package / Recv-Info) CRLF Info-Package = "Info-Package" HCOLON Info-package-type Recv-Info = "Recv-Info" HCOLON [Info-package-list] Info-package-list = Info-package-type *( COMMA Info-package-type ) Info-package-type = Info-package-name *( SEMI Info-package-param) Info-package-name = token Info-package-param = generic-param 10. Info Package Requirements 10.1. General This section provides guidance on how to define an Info Package, and what information needs to exist in an Info Package specification. If, for an Info Package, there is a need to extend or modify the behavior described in this document, that behavior MUST be described in the Info Package specification. It is bad practice for Info Package specifications to repeat procedures defined in this document, unless needed for clarification or emphasis purpose. Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, Info Packages specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if applications associated with the Info Package require it. Info Package specifications MUST address the issues defined in the following subsections, or document why an issue is not applicable for the specific Info Package. Section7.38.3 describes alternative mechanisms, which should be considered as part of the process for solving a specific use-case, when there is a need for transporting application information. 10.2. Overall Description The Info Package specification MUST contain an overall description of the Info Package: what type of information are carried in INFO requests associated with the Info Package, and for what type of applications and functionalities UAs can use the Info Package. If the Info Package is defined for a specific application, the Info Package specification MUST state which application UAs can use the Info Package with. 10.3. Applicability The Info Package specification MUST describe why the Info Package mechanism, rather than some other mechanism, has been chosen for the specific use-case to transfer application information between SIP endpoints. Common reasons can be a requirement for SIP Proxies or back-to-back user agents (B2BUAs) to see the transported application information (which would not be the case if the information was transported on a media path), or that it is not seen feasible to establish separate dialogs (subscription) in order to transport the information. Annex A provides more information, and describes alternative mechanisms which one should consider for solving a specific use-case. 10.4. Info Package Name The Info Package specification MUST define an Info Package name, which UAs use as a header field value (e.g. "infoX") to identify the Info Package in the Recv-Info and Info-Package header fields. The header field value MUST conform to the ABNF defined in Section8.2.9.2. The Info Package mechanism does not support package versioning. Specific Info Package message body payloads can contain version information, which is handled by the applications associated with the Info Package. However, such feature is outside the scope of the generic Info Package mechanism. NOTE: Even if an Info Package name contains version numbering (e.g. foo_v2), the Info Package mechanism does not distinguish a version number from the rest of the Info Package name. 10.5. Info Package Parameters The Info Package specification MAY define Info Package parameters, which can be used in the Recv-Info or Info-Package header fields, together with the header field value which indicates the Info Package name (see Section 10.4. The Info Package specification MUST define the syntax and semantics of the defined parameters. In addition, the specification MUST define whether a specific parameter is only applicable to the Recv- Info header field, the Info-Package header field, or both. By default, an Info Package parameter is only applicable for the Info Package for which the parameter has been explicitly defined. Info Package parameters defined for specific Info Packages can share the name with parameters defined for other Info Packages, but the parameter semantics are specific to the Info Package for which they are defined. However, when choosing the name of a parameter it is RECOMMENDED to not use the same name as an existing parameter for another Info Package, if the semantics of the parameters are different. 10.6. SIP Option Tags The Info Package specification MAY define SIP option tags, which can be used as described in[RFC3261].RFC 3261. The registration requirements for option tags are defined in RFC 5727 [RFC5727]. 10.7. INFO Message Body Parts The Info Package specification MUST define which message body part MIME types are associated with the Info Package. The specification MUST either define those body parts, which include the syntax, semantics and MIME type of the each body part, or refer to other documents which define the body parts. If multiple message body part MIME types are associated with an Info Package, the Info Package specification MUST define whether UAs need to use multipart body parts in order to include multiple body parts in a single INFO request. 10.8. Info Package Usage Restrictions If there are restrictions on how UAs can use an Info Package, the Info Package specification MUST document such restrictions. There can be restrictions related to whether UAs are allowed to send overlapping (outstanding) INFO requests associated with the Info Package, or whether the UA has to wait for the response for a previous INFO request associated with the same Info Package. There can also be restrictions related to whether UAs need to support and use other SIP extensions and capabilities when they use the Info Package, and if there are restrictions related to how UAs can use the Info-Package together with other Info Packages. As the SIP stack might not be aware of Info Package specific restrictions, it cannot be assumed that overlapping requests would be rejected. As defined in Section3.2.2,4.2.2, UAs will normally send a 200 (OK) response to an INFO request. The application logic associated with the Info Package needs to handle situations where UAs do not follow restrictions associated with the Info Package. 10.9. Rate of INFO Requests If there is a maximum or minimum rate at which UAs can send INFO requests associated with the Info Package within a dialog, the Info Package specification MUST document the rate values. If the rates can vary, the Info Package specification MAY define Info Package parameters that UAs can use to indicate or negotiate the rates. Alternatively the rate information can be part of the application data information associated with the Info Package. 10.10. Info Package Security Considerations If the application information carried in INFO requests associated with the Info Package requires a certain level of security, the Info Package specification MUST describe the mechanisms that UAs need to use in order to provide the required security. If the Info Package specification does not require any additional security, other than what the underlying SIP protocol provides, it MUST be stated in the Info Package specification. NOTE: In some cases, it may not be sufficient to mandate TLS in order to secure the Info Package payload, since intermediaries will have access to the payload, and beyond the first hop, there is no way to assure subsequent hops will not forwards the payload in clear text. The best way to ensure secure transport at the application level is to have the security at the application level. One way of achieving this is to use end-to-end security techniques such as S/MIME [RFC5751]. 10.11. Implementation Details It is strongly RECOMMENDED that the Info Package specification defines the procedure how implementors shall implement and use the Info Package, or refer to other locations where implementors can find that information. NOTE: Sometimes Info Package designer might choose to not reveal the details of an Info Package. However, in order to allow multiple implementations to support the Info Package, Info Package designers are strongly encouraged to provide the implementation details. 10.12. Examples It is RECOMMENDED that the Info Package specification provides demonstrative message flow diagrams, paired with complete messages and message descriptions. Note that example flows are by definition informative, and do not replace normative text. 11. IANA Considerations 11.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] 11.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. Header Name: Info-Package Compact Form: (none) Reference: [RFCXXXX] 11.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] 11.4. Creation of the Info Packages Registry Please create a subregistry in the SIP Parameters registry for Info Packages. Note to the reviewer: The policy for review of Info Packages is "Specification Required", as defined in [RFC5226]. This policy was selected because Info Packages re-use an existing mechanism for transport of arbitrary session-associated data within SIP, and therefore new Info Packages do not require the more extensive review required by specifications that make fundamental protocol changes. However, the reviewer is expected to verify that each Info Package registration is in fact consistent with this definition. Changes to the SIP protocol and state machine are outside of the allowable scope for an Info Package and are governed by other procedures including[RFC5727]RFC 5727 and its successors, if any. The following data elements populate the Info Package Registry. o Info Package Name: The Info Package Name is a case-sensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values. o Reference: A reference to a specification which describes the Info Package. The initial population of this table shall be: Name Reference 11.5. Registration of the Info-Package Content-Disposition Please add the following new header field value to the Content- Disposition registry. Name: info-package Description: the body contains information associated with an Info Package Reference: RFCXXXX 11.6. SIP Response Code 469 Registration Please register the following new response code in the Session Initiation Protocol Parameters - Response Codes registry. Response Code: 469 Default Reason Phrase: Bad Info Package Reference: RFCXXXX 12. Examples 12.1. Indication for which Info Packages UAs are willing to receive INFO requests 12.1.1. Initial INVITE request The UAC sends an initial INVITE request, where the UAC indicates that it is willing to receive INFO requests for Info Packages P and R. INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Recv-Info: P, R Contact: <sip:alice@pc33.example.com> Content-Type: application/sdp Content-Length: ... ... The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R and T. SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;received=192.0.2.1 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 INVITE Contact: <sip:bob@pc33.example.com> Recv-Info: R, T Content-Type: application/sdp Content-Length: ... ... The UAC sends an ACK request. ACK sip:bob@pc33.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314159 ACK Content-Length: 0 12.1.2. Target refresh The UAC sends an UPDATE request within the invite dialog usage, where the UAC indicates (using an empty Recv-Info header field) that it is not willing to receive INFO requests for any Info Packages. UPDATE sip:bob@pc33.example.com SIP/2.0 Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776 Max-Forwards: 70 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314163 UPDATE Recv-Info: Contact: <sip:alice@pc33.example.com> Content-Type: application/sdp Content-Length: ... ... The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R, T. SIP/2.0 200 OK Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;received=192.0.2.1 To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.example.com CSeq: 314163 INVITE Contact: <sip:alice@pc33.example.com> Recv-Info: R, T Content-Type: application/sdp Content-Length: ... ... 12.2. INFO request associated with Info Package 12.2.1. Single payload The UA sends an INFO request associated with Info Package foo. INFO sip:alice@pc33.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef To: Bob <sip:bob@example.com>;tag=a6c85cf From: Alice <sip:alice@example.com>;tag=1928301774 Call-Id: a84b4c76e66710@pc33.example.com CSeq: 314333 INFO Info-Package: foo Content-type: application/foo Content-Disposition: Info-Package Content-length: 24 I am a foo message type 12.2.2. Multipart INFO 12.2.2.1. Non-Info Package body part SIP extensions can sometimes add body part payloads into an INFO request, independent of the Info Package. In this case, the Info Package payload gets put into a Multipart MIME body, with a Content- Disposition header field that indicates which body part is associated with the Info Package. INFO sip:alice@pc33.example.com 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: a84b4c76e66710@pc33.example.com CSeq: 314400 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Length: ... --theboundary Content-Type: application/mumble ... <mumble stuff> --theboundary Content-Type: application/foo-x Content-Disposition: Info-Package Content-length: 59 I am a foo-x message type, and I belong to Info Package foo --theboundary-- 12.2.2.2. Info Package with multiple body parts inside multipart body part Multiple body part payloads can be associated with a single Info Package. In this case, the body parts are put into a Multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package. INFO sip:alice@pc33.example.com 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: a84b4c76e66710@pc33.example.com CSeq: 314423 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ... --theboundary Content-Type: application/foo-x Content-length: 59 I am a foo-x message type, and I belong to Info Package foo <mumble stuff> --theboundary Content-Type: application/foo-y Content-length: 59 I am a foo-y message type, and I belong to Info Package foo --theboundary-- 12.2.2.3. Info Package with single body part inside multipart body part The body part payload associated with the Info Package can have a Content-Disposition header field value other than "Info-Package". In this case, the body part is put into a Multipart MIME body, with a Content-Disposition header field that indicates which body part is associated with the Info Package. INFO sip:alice@pc33.example.com 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: a84b4c76e66710@pc33.example.com CSeq: 314423 INFO Info-Package: foo Content-Type: multipart/mixed;boundary="theboundary" Content-Disposition: Info-Package Content-Length: ... --theboundary Content-Type: application/foo-x Content-Disposition: icon Content-length: 59 I am a foo-x message type, and I belong to Info Package foo --theboundary-- 13. Security Considerations By eliminating multiple usages of INFO messages without adequate community review and by eliminating the possibility for rogue SIP UAs from confusing another UA by purposely sending unrelated INFO requests,as described in Section 9.2,we expect this document's clarification of the use of INFO to improve the security of the Internet. Whilst rogue UAs can still send unrelated INFO requests, this mechanism provides mechanisms for which the UAS and other security devices can associate INFO requests with Info Packages that have been negotiated for a session. If the content of the Info Package payload is private, UAs will need to use end-to-end encryption, such as S/MIME, to prevent access to the content. This is particularly important as transport of INFO is likely not to be end-to-end, but through SIP proxies and back-to-back user agents (B2BUA's), which the user may not trust. The INFO request transports application level information. One implication of this is INFO messages may require a higher level of protection than the underlying SIP dialog 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. This means some applications may require end-to-end encryption of the INFO payload, beyond, for example, hop-by-hop protection of the SIP signaling itself. Since the application dictates the level of security required, individual Info Packages have to enumerate these requirements. In any event, the Info Package mechanism described by this document provides the tools for such secure, end-to-end transport of application data. 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. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [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. [RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009. [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010. 14.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [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. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004. [RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", BCP 63, RFC 3372, September 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.[RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. [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 Initiation Protocol", RFC 5057, November 2007. [RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, March 2008. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. [RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup Language (MSML)", RFC 5707, February 2010. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [W3C.REC-voicexml21-20070619]Porter, B., Oshry, M., Bodell, M.,Rehor, K.,McGlashan, S.,Bodell, M., Burke, D., Baggia, P., Auburn, R.,Candell, E.,Burnett, D., Candell, E., Carter, J.,Baggia, P., and A.McGlashan, S., Lee, A., Porter, B., and M. Oshry, "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>. [I-D.ietf-speechsc-mrcpv2]Shanmugham, S. and D.Burnett, D. and S. Shanmugham, "Media Resource Control Protocol Version 2 (MRCPv2)",draft-ietf-speechsc-mrcpv2-20draft-ietf-speechsc-mrcpv2-21 (work in progress),August 2009.July 2010. [Ecma-355] "Standard ECMA-355 Corporate Telecommunication Networks - Tunnelling of QSIG over SIP", ECMA http:// www.ecma-international.org/publications/standards/ Ecma-355.htm, June 2008. Appendix A.Legacy INFO Usage A.1. General This section provides examples of existing legacy INFO usages. The section is not meant to be a comprehensive catalog of legacy INFO usages, but it should give the reader a flavor for current legacy INFO usages. A.2. ISUP [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP message bodies. ITU-T and 3GPP have specified similar procedures. A.3. QSIG [Ecma-355] specifies the encapsulation of QSIG in SIP message bodies. A.4. MSCML [RFC5022] specifies how INFO is used as a transport mechanism by the Media Server Control Markup Language (MSCML) protocol. MSCML uses an option-tag in the Require header field to ensure that the receiver understands the INFO content. A.5. MSML [RFC5707] specifies how INFO us used as a transport mechanism by the Media Server Markup Language (MSML) protocol. A.6. Video Fast Update Companies have been using INFO messages in order to request fast video update. Currently a standardized mechanism, based on RTCP, has been specified in [RFC5168] A.7. DTMF Companies have been using INFO messages in order to transport DTMF tones. All mechanisms are proprietary, and have not been standardized. Appendix B.Acknowledgements The work on this document was influenced by the "INFO Considered Harmful" draft (26 December 2002) written by Jonathan Rosenberg, and by the "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" draft (15 January 2003) written by Dean Willis. The following individuals have been involved in the work, and have provided input and feedback on this document: Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Johnathan Rosenberg, Juha Heinanen, Gordon Beith, 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, Roni Evan Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg and Xavier Marjoum. John Elwell and Francois Audet helped with QSIG references. In addition, Francois Audet provided text for the revised abstract. Keith Drage provided comments and helped immensely with Figure 1. Arun Arunachalam, Brett Tate, John Elwell, Keith Drage and Robert Sparks provided valuable feedback during the WGLC process, in order to prepare this document for publication. Adam Roach, Dean Willis, John Elwell and Paul Kyzivat provided valuable input in order to sort out the message body part usage for Info Packages. AppendixC.B. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-ietf-sipcore-info-events-09 o New Motivation section added o Old section 9 and Annex A removed Changes from draft-ietf-sipcore-info-events-08 o Further changes based on IESG comments o Editorial changes o Section 7.3 removed o New section 7.4.1.2. added, containing text from old section 7.3 Changes from draft-ietf-sipcore-info-events-07 o Further changes based on WGLC comments o Editorial changes o IANA registry procedures clarified o Reference to RFC 5727 added Changes from draft-ietf-sipcore-info-events-05 o Further changes based on WGLC comments o Editorial changes o IANA registry procedures clarified Changes from draft-ietf-sipcore-info-events-04 o Further changes based on WGLC comments o OPTIONS processing removed o Clarification of Recv-Info header field in INFO 469 response added o IANA registry procedures clarified Changes from draft-ietf-sipcore-info-events-03 o Further changes based on WGLC comments o New section 3.2.3 added Changes from draft-ietf-sipcore-info-events-02 o Further changes based on WGLC comments o alignment with "specification" and "definition" terminology o Location switch of sections 3 and 4 o Corrections in header table o IANA Info Package registration input changed o Clarification regarding which SIP messages can contain the Recv- Info header field o Recv-Info 'nil' value removed o Rules on usage of Recv-Info header clarified o Recv-Info fallback rules added o Additional examples added Changes from draft-ietf-sipcore-info-events-01 o Further changes based on WGLC comments o Appending A moved into the main part of the document o Section name changed from "Modifications to SIP Change Process" to "Security Considerations" o "Syntax" section moved further up in the document o Clarification on usage of Info Package related message body parts, and the usage of the Content-Disposition header field with those body parts o Removed REFER and NOTIFY from the INFO Headers table o Clarified usage of the Recv-Info header field in the REGISTER and OPTIONS requests o Major re-write of the Introduction section o Text about legacy INFO and subscription-based events moved from the Introduction to the main part of the document o Wording about receiving Info-Packages has been replaced with wording about receiving INFO requests for Info-Packages o The text about the usage of message body, and body parts, associated with Info Packages, has been clarified Changes from draft-ietf-sip-info-events-04 o Major re-write of the document, due to problems to implement WGLC comments into the existing text structure o Wording alignment o Clarification or roles Changes from draft-ietf-sip-info-events-03 o Clarified Abstract language o All SIP dialogs are now referred to as sessions o Clarified the image example in the Introduction o Clarified the relationship (none) between SIP Event Packages and SIP Info Packages o Really, really clarified the protocol is NOT a negotiation but an advertisement o Split Section 3 into UAS and UAC behavior o Moved the example in section 3 into its own sub-section, and used full SIP header fields o Clarified forking behavior o Clarified language around when to send a body o Added 469 error response, instead of reusing 489 o Clarified overlapping INFO method handling o Fixed table 1 to follow 3261, not 2543 o Added REFER to the INFO Headers table o Replaced token-nodot with token for Info-Package header field values o Clarified end-to-end security considerations o Info Package parameters are semi-colon delimited, not dot delimited Changes from -02 o Applicability statement explicitly says we're backwards compatible o Explicitly state we work like UPDATE (both early and confirmed dialogs) o Agreed text for IANA Considerations package registry Changes from -01 o One and only one Info Package per INFO o Removed Send-Info header field, greatly simplifying negotiation o Multiple body part identification through Content-Disposition: Info-Package o Note that forking INVITEs may result in multiple INFOs coming back to INVITE originator o Describe how a UAS can enforce strict adherence to this document o Remove CANCEL INFO faux pas o Better explained overlapping INFO issues and resolutions o Token names are now really case sensitive o Moved Info Package Considerations to an Appendix o Introduced stronger, yet more open, IANA registration process o Took a few more paragraphs from INFO Litmus to cover all bases. o Added RFC 5168 to legacy usages Changes from -00 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 field 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 Christer Holmberg Ericsson Hirsalantie 11 Jorvas, 02420 Finland Phone: Fax: Email: christer.holmberg@ericsson.com URI: Eric W. Burger NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166-6579 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: