Internet DRAFT - draft-kaplan-sip-info-events

draft-kaplan-sip-info-events




SIP Working Group                                             H. Kaplan 
Internet Draft                                              Acme Packet 
Intended status: Standards Track                            C. Holmberg 
Expires: August 25, 2008                                       Ericsson 
                                                              E. Burger 
                                                      BEA Systems, Inc. 
                                                      February 25, 2008 
    
    
              The SIP INFO Method and Info Package Framework 
                      draft-kaplan-sip-info-events-01 
    
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79.  
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts.  
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress".  
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.txt.  
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
    
   This Internet-Draft will expire on August 25, 2008.  
    
Copyright Notice 
    
   Copyright (C) The IETF Trust (2008). 
    








 
 
Kaplan, et al.         Expires August 25, 2007               [Page 1]
                The SIP INFO Method and Info Packages   February 2008 
 
 
Abstract 
    
   This document defines the INFO method and a mechanism for defining, 
   negotiating and exchanging Info Packages in it.  INFO requests are 
   used within SIP INVITE-created dialogs, for applications which need 
   to exchange session-related information inside the INVITE-created 
   dialog.  This draft addresses issues and open items from RFC 2976, 
   and replaces it. 
    
Table of Contents 
    
   1.     Introduction..........................................3 
   1.1.   Background............................................4 
   2.     Terminology...........................................4 
   3.     Applicability.........................................5 
   4.     The INFO Method Request...............................5 
   4.1.   Responses to the INFO Request Method..................6 
   4.2.   Message Body Inclusion................................6 
   4.3.   Behavior of SIP User Agents...........................7 
   4.4.   Behavior of SIP Proxy and Redirect Servers............7 
   4.4.1  Proxy Server..........................................7 
   4.4.2  Forking Proxy Server..................................7 
   4.4.3  Redirection Server....................................7 
   4.5.   INFO Message Bodies...................................7 
   5.     Info Package Negotiation..............................8 
   5.1.   Info Package Negotiation Overview.....................8 
   5.2.   UAC Behavior..........................................8 
   5.3.   UAS Behavior..........................................9 
   6.     General..............................................10 
   6.1.   Re-Invites and usages and forks, oh my!..............10 
   6.2.   Detecting support for INFO and Info Packages.........11 
   7.     Legacy Uses of INFO..................................11 
   8.     Info Packages........................................12 
   8.1.   Appropriateness of Usage.............................12 
   8.1.1  Dialog Fate-Sharing..................................12 
   8.1.2  Messaging Rates and Volume...........................13 
   8.1.3  Proxy-path Signaling.................................13 
   8.1.4  Is there a better alternative?.......................13 
   8.2.   Info Package Responsibilities........................14 
   8.2.1  Info Package Name....................................14 
   8.2.2  Info Package Parameters..............................14 
   8.2.3  INFO Bodies..........................................14 
   8.2.4  UA generation of INFO requests.......................15 
   8.2.5  UA processing of INFO requests.......................15 
   8.2.6  Rate of notifications................................15 
   8.2.7  Examples.............................................15 
   9.     Syntax...............................................15 
   9.1.   New Method...........................................16 
   9.1.1  INFO Method..........................................17 
 
 
Kaplan, et al.         Expires - August 2008                [Page 2]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   9.2.   New Headers..........................................17 
   9.2.1  "Info-Package" header................................17 
   9.2.2  "Send-Info" header...................................18 
   9.2.3  "Recv-Info" header...................................18 
   9.3.   Augmented BNF Definitions............................18 
   10.    Example Exchange.....................................19 
   11.    Security Considerations..............................20 
   12.    IANA Considerations..................................20 
   13.    Acknowledgements.....................................20 
   14.    References...........................................21 
   14.1.  Normative References.................................21 
   14.2.  Informative References...............................21 
   Authors' Addresses..........................................22 
   Full Copyright Statement....................................23 
   Intellectual Property Statement.............................23 
   Acknowledgment..............................................23 
    
    
1. Introduction 
    
   The SIP protocol described in [RFC3261] defines session control 
   messages used during the setup and tear down stages of a SIP 
   controlled session.  In addition, the SIP re-INVITE and UPDATE can 
   be used during a session to change the characteristics of the 
   session.  This is generally to change the properties of media flows 
   related to the session or to update the SIP session timer per 
   [RFC4028].  The purpose of the INFO message, on the other hand, is 
   to carry application level information along the SIP signaling path. 
    
   The INFO method is not used to change the state of SIP calls, or the 
   parameters of the sessions SIP initiates.  It merely sends optional 
   application layer information, generally related to the session. 
    
   It is necessary that the mid-dialog signaling information traverse 
   the post session setup SIP signaling path.  This is the path taken 
   by SIP re-INVITEs, BYEs and other SIP requests that are tied to an 
   individual dialog.  This allows SIP proxy servers to receive, and 
   potentially act on, the mid-dialog signaling information.  The SIP 
   INFO method was defined in [RFC2976] to convey such session related 
   control information inside an INVITE-created dialog.  This draft is 
   meant to replace [RFC2976] SIP INFO. 
    
   While INFO use has been widely adopted for specific application use 
   cases, such as ISUP and DTMF exchange, the original RFC did not 
   define a negotiation mechanism nor a means by which to explicitly 
   indicate the type of application information contained in the INFO.  
   This led to problems associated with static configuration, and 
   potential interoperability problems due to undefined content syntax 
   and semantics.  This draft aims at addressing those deficiencies, to 
 
 
Kaplan, et al.         Expires - August 2008                [Page 3]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   provide a framework for explicit negotiation of capabilities and 
   content context using "Info Packages".   
    
   This document does not describe any specific Info Package type 
   extensions which may be used directly; it must be extended by other 
   documents (herein referred to as "Info Packages").  In object-
   oriented design terminology, it may be thought of as an abstract 
   base class which must be derived into an instantiated class by 
   further extensions.  Guidelines for creating these extensions are 
   described in section 8. 
    
1.1. Background 
    
   The INFO method as defined in [RFC2976] did not provide any context 
   for the information which it carries.  While it may sometimes be 
   clear what the content is, based on the Content-Type, such is only 
   true while only one contextual usage of the content-type is ever 
   employed.  For example, if the Content-Type were "image/jpeg", it 
   would be clear that the MIME-attached content was a JPEG image, but 
   not what its purpose was.  It could be being sent as a caller-id 
   picture, or as a contact-icon, or whatever.  The sender is not sure 
   which JPEG to give the receiver if it supports a JPEG content-type, 
   and the receiver does not know which JPEG is being sent if it 
   supports receiving more than one.  Thus there needs to be a well-
   defined and documented statement of what the information sent is 
   for.  Event Packages, as defined in [RFC3265] perform that role for 
   Subscription-based events, whereas this document provides a similar 
   framework for INVITE-based information exchange.  However this 
   document does NOT use the Events Package semantics of Subscriptions, 
   and is wholly unrelated to [RFC3265]. 
    
   Unlike [RFC3265], the mechanism defined in this draft is not based 
   on the usage of the SUBSCRIBE and NOTIFY methods, and does not 
   create a separate subscription dialog or a subscription usage within 
   an existing dialog.  Instead, it uses the INVITE method and its 
   responses to indicate and negotiate supported Info Packages, and the 
   INFO method to convey the Info Packages.  This mechanism is not 
   appropriate for IANA-registered Subscribe Event package types, and 
   support for this mechanism should be explicitly indicated in future 
   Info Package definitions and registrations. 
    
    
2. Terminology 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119.  The 
   terminology in this document conforms to RFC 2828, "Internet 
   Security Glossary". 
 
 
Kaplan, et al.         Expires - August 2008                [Page 4]
                The SIP INFO Method and Info Packages   February 2008 
 
 
    
3. Applicability 
    
   This draft proposes replacing the [RFC2976] SIP INFO method document 
   to include explicit negotiation of supported Info Packages in the 
   INVITE transaction, and indication of the indicated Info Package 
   using a new header field in the INFO request. 
    
4. The INFO Method Request 
    
   The INFO method is used for communicating mid-session signaling 
   information along the signaling path for the call. The INFO method 
   is not used to change the state of SIP calls, nor does it change the 
   state of sessions initiated by SIP.  Rather, it provides additional 
   optional information which can further enhance the application using 
   SIP.  There are some types of application information for which 
   using INFO messages is inappropriate - a discussion of this can be 
   found in section 8.1. 
    
   This draft creates a new, mandatory header field for INFO requests: 
   the "Info-Package" header field.  The "Info-Package" header field 
   value in an INFO request will contain a single Info Package token 
   name which is being signaled by the INFO request.  The token in the 
   "Info-Package" header field value MUST match one of the Info Package 
   tokens received in the "Recv-Info" header field value in the 
   received INVITE for the UAS, or response for the UAC.  In other 
   words one can only send what the other end is willing to receive. 
    
   The INFO method can only be used within an INVITE-generated dialog 
   (early or full) and usage.  It has no lifetime or usage of its own, 
   as it is inexorably linked to that of the INVITE.  When the INVITE-
   created dialog is terminated, the lifetime of the negotiated Info 
   Packages is also terminated.  Any INFO message received after a BYE 
   or CANCEL has been sent MUST be responded to with a 481 Call Does 
   Not Exist. 
    
   The dialog identifiers defined in [RFC3261] must match those of the 
   provisional or final responses to the INVITE, and as a result INFO 
   requests do not fork.  INFO requests may be sent in either 
   direction, once the UAC or UAS has received the Send-Info/Recv-Info 
   header field value indications of what the far-end supports.  For 
   the UAS, it MUST receive the ACK for the INVITE's 200-ok, or the 
   PRACK for a provisional response, before sending an INFO request.  
   In other words it must know the far-end UAC has received its 
   indication of what Info Packages it is willing to send before it 
   sends them. 
    
   The signaling path for the INFO method is the signaling path 
   established as a result of the call setup.  This can be either 
 
 
Kaplan, et al.         Expires - August 2008                [Page 5]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   direct signaling between the calling and called user agents or a 
   signaling path involving SIP proxy servers that were involved in the 
   call setup and added themselves to the Record-Route header on the 
   initial INVITE message. 
    
   The mid-session information can be communicated in either an INFO 
   message header or as part of an INFO message body.  The definition 
   of the message body and/or message headers used to carry the mid-
   session information is defined by the specific named Info Package 
   definition.  The semantics are derived from the specific Info 
   Package extension documented for usage in INFO. 
    
4.1. Responses to the INFO Request Method 
    
   If a server receives an INFO request it MUST send a final response.  
   A 200 OK response MUST be sent by a UAS for an INFO request with no 
   message body if the INFO request was successfully received for an 
   existing call.  Beyond that, no additional operations are    
   required. 
    
   A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a 
   UAS if the INFO request does not match any existing call leg. 
    
   If a server receives an INFO request with a body it understands, but 
   it has no knowledge of Info Package associated processing rules for 
   the body, the body MAY be rendered and displayed to the user.  The 
   INFO is responded to with a 200 OK. 
    
   If the INFO request contains a body that the server does not 
   understand then, in the absence of Info Package associated 
   processing rules for the body, the server MUST respond with a 415 
   Unsupported Media Type message. 
    
   If the INFO request indicates an Info Package type that the server 
   does not understand, then the server MUST respond with a [TBD: 405 
   or 501 seem most appropriate, and do not terminate the INVITE 
   dialog]. 
    
   Bodies which imply a change in the SIP call state or the sessions 
   initiated by SIP MUST NOT be sent in an INFO message.  Other request 
   failure (4xx), Server Failure (5xx) and Global Failure (6xx) 
   responses MAY be sent for the INFO Request. 
    
4.2. Message Body Inclusion 
    
   The INFO request MAY contain a message body, which MUST be specified 
   by the Info Package type extension document.  INFO bodies are 
   expected to provide additional details about the nature of the 

 
 
Kaplan, et al.         Expires - August 2008                [Page 6]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   information being exchanged and the resultant resource state, if 
   any. 
    
4.3. Behavior of SIP User Agents 
    
   Unless stated otherwise, the protocol rules for the INFO request 
   governing the usage of tags, Route and Record-Route, retransmission 
   and reliability, CSeq incrementing and message formatting follow 
   those in [RFC3261] as defined for the BYE request. 
    
   An INFO request MAY be cancelled.  A UAS receiving a CANCEL for an 
   INFO request SHOULD respond to the INFO with a "487 Request 
   Cancelled" response if a final response has not been sent to the 
   INFO and then behave as if the request were never received. 
        
   However, the INFO message MUST NOT change the state of the SIP call, 
   or the INVITE sessions initiated by SIP.  The only exception to this 
   rule is for specific failure responses as documented in [RFC5057], 
   which may cause the INVITE dialog to terminate. 
    
4.4. Behavior of SIP Proxy and Redirect Servers 
    
   [Do we still need to handle 3 different types of Proxies this way?  
   This is from RFC2976] 
    
4.4.1     Proxy Server 
    
   Unless stated otherwise, the protocol rules for the INFO request at 
   a proxy are identical to those for a BYE request as specified in 
   [RFC3261]. 
    
4.4.2     Forking Proxy Server 
    
   Unless stated otherwise, the protocol rules for the INFO request at 
   a proxy are identical to those for a BYE request as specified in 
   [RFC3261]. 
    
4.4.3     Redirection Server 
    
   Unless stated otherwise, the protocol rules for the INFO request at 
   a proxy are identical to those for a BYE request as specified in 
   [RFC3261]. 
    
    
4.5. INFO Message Bodies 
    
   The purpose of the INFO message is to carry mid-session information 
   between SIP user agents.  This information will generally be carried 

 
 
Kaplan, et al.         Expires - August 2008                [Page 7]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   in message bodies, although it can be carried in headers in the INFO 
   message. 
    
   The definition of the message bodies or any new headers created for 
   the INFO method MUST be defined by separately documented Info 
   Package extensions.  Info Packages MUST define semantics associated 
   with the body of their INFO requests. 
    
   In addition, the INFO method does not define additional mechanisms 
   for ensuring in-order delivery.  While the CSeq header will be 
   incremented upon the transmission of new INFO messages, this should 
   not be used to determine the sequence of INFO information.  This is 
   due to the fact that there could be gaps in the INFO message CSeq 
   count caused by a user agent sending re-INVITES or other SIP 
   messages. 
    
5. Info Package Negotiation  
    
5.1. Info Package Negotiation Overview 
    
   The general concept is that the UAC generating an INVITE request 
   includes the Info Package types it supports sending and receiving, 
   in two new header fields: Send-Info and Recv-Info.  If the UAS 
   supports this mechanism, it responds with the Info Packages it 
   wishes to actually receive and send in the same named header fields 
   (in reverse), in the provisional and final responses.  When either 
   side has indication of what the far-end supports, it may send the 
   information defined by the Info Packages in an INFO request, 
   following the same INVITE-created dialog and usage.  The INFO 
   request indicates the specific Info Package it is associated with, 
   using an "Info-Package" header field with the Info Package type 
   name, and any associated MIME-attached body defined for that Info 
   Package.  
    
   The UAC and UAS MUST negotiate which Info Packages are supported and 
   will be used in which direction, before sending an INFO message for 
   any specific Info Package.  Negotiation always starts with the UAC 
   indicating which Info Packages it supports and wishes to send or 
   receive, using the two new header fields "Send-Info" and "Recv-
   Info", in the INVITE request.  The UAS always indicates which Info 
   Packages, of those offered by the UAC, it wishes to accept for 
   sending and receiving to/from the UAC in its responses. 
    
5.2. UAC Behavior 
    
   A UAC supporting this draft MAY indicate one or more Info Packages 
   it wishes to support sending during the Invite dialog, by including 
   their RFC-defined names in the "Send-Info" header field value in the 
   INVITE request.  Not including the Send-Info header field in the 
 
 
Kaplan, et al.         Expires - August 2008                [Page 8]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   INVITE means the UAC does not have an intention, and MUST NOT, send 
   any Info Packages during the dialog. 
 
   The UAC MAY indicate one or more Info Packages it wishes to support 
   receiving during the Invite-created dialog, by including their Info 
   Package names in the "Recv-Info" header field in the INVITE request. 
   Not including the Recv-Info header field in the INVITE means the UAC 
   will not accept Info Packages during the dialog. 
    
   When the UAC receives a Recv-Info header field in any provisional 
   1xx or 2xx response, it is an indication from the far-end UAS that 
   it (the UAS) supports receiving the Info Packages indicated in the 
   header field value.  Any indicated Info Packages in the Recv-Info 
   header field value from the UAS which were not offered by the UAC in 
   a Send-Info header field value MUST be ignored, and MUST NOT 
   constitute a protocol failure.  In other words such mismatches do 
   not fail the negotiation - the extraneous Info Packages are merely 
   ignored. 
    
   When the UAC receives a Send-Info header field in any provisional 
   1xx or 2xx final response, it is an indication from the far-end UAS 
   that it (the UAS) supports sending Info Package(s) named in the 
   header field value.  Any indicated Send-Info header field values 
   from the UAS which were not offered by the UAC in a Recv-Info header 
   field value MUST be ignored, and MUST NOT constitute a protocol 
   failure. 
    
   Once an early dialog is established, through a 1xx provisional 
   response with To-tags, and the UAC has received a Recv-Info header 
   field values from the UAS in the response, the UAC MAY send any Info 
   Packages supported by the UAS in an INFO message.  The 2xx final 
   response updates the state of the supported Info Packages, such that 
   the 2xx contains the full and final list of Send-Info and Recv-Info 
   Info Packages.  If the 2xx does not contain a Send-Info header 
   field, the UAS is indicating it will not send any, and if it does 
   not contain a Recv-Info header field, the UAS will not accept any, 
   regardless of what a previous 1xx response might have indicated.  At 
   this point negotiation is considered complete. 
    
5.3. UAS Behavior 
    
   When a UAS receives an INVITE request, it checks for a Send-Info and 
   Recv-Info header fields.  One or both may exist.  For each Info 
   Package name in the received Send-Info header field value, the UAS 
   decides if it wishes to accept receiving such Info Packages from the 
   UAC.  If so, it MUST copy the type token name(s) of those acceptable 
   Info Packages into a Recv-Info header field value in any, and all 
   subsequent, provisional 1xx and final 2xx responses.   
    
 
 
Kaplan, et al.         Expires - August 2008                [Page 9]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   For each Info Package name listed in the received Recv-Info header 
   field value, the UAS decides if it wishes to send such Info Packages 
   to the UAC.  If so, it MUST copy the name(s) of those Info Packages 
   it wishes to generate into a Send-Info header field value in any, 
   and all subsequent, provisional 1xx and final 2xx responses. 
    
   Note that "any, and all subsequent," means that the UAS MAY decide 
   not to indicate any Info Packages in early 1xx responses; but once 
   it indicates such in a 1xx, it MUST continue to do so in subsequent 
   responses including the final 2xx response in order to keep the Info 
   Package support state the same.  If the UAS no longer wishes to 
   support them after the provisional response, it MUST indicate such 
   by removing them from the Send-Info or Recv-Info header field values 
   in any subsequent provisional and the 2xx final response, and if no 
   Info Packages are remaining then by not including the appropriate 
   header field(s). 
    
   The UAS MUST NOT send any INFO messages with Info Packages until it 
   has received an acknowledgement (e.g. PRACK for a provisional 
   response, or an ACK for a final response it sent) that the UAC has 
   received the SIP response sent by the UAS, indicating that the UAC 
   has received the Send-Info header field values from the UAS.  This 
   assures the UAC can perform any necessary logic it needs to in order 
   to receive the Info Package, and can associate the INFO message and 
   associated Info Package with the proper dialog. 
    
   NOTE: Unlike the NOTIFY method, the INFO method CAN NOT be used to 
   establish a dialog. 
    
6. General  
    
6.1. Re-Invites and usages and forks, oh my! 
    
   A Re-INVITE or UPDATE request MUST NOT contain any Send-Info or 
   Recv-Info header fields, and such header fields MUST be ignored on 
   reception.  The Info Package negotiation is performed during the 
   initial INVITE transaction, and there is no re-negotiation. 
    
   [Is that ok?  Is there a need to have re-negotiation? (is there a 
   use case?)  It sure makes it simple not to have things change in the 
   middle of a session.  Adam points out 3PCC needs it - TBD by SIP-WG] 
    
   There is no separate "usage" for the INFO request, as defined by 
   [RFC5057].  The INFO is related to but not integral to the Invite 
   usage, such that some failure responses to an INFO request do not 
   affect the INVITE usage whatsoever, as described in [RFC5057].  
   Other failures may terminate the usage or dialog completely.  The 
   lifetime of Info Packages is exactly the same as that of the INVITE.  

 
 
Kaplan, et al.         Expires - August 2008               [Page 10]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   If an INVITE usage fails or is terminated, the Info Package-based 
   state no longer exists, and an INFO request MUST NOT be sent. 
    
   The original INVITE request may be forked along the path, resulting 
   in multiple 1xx provisional responses, each with a separate set of 
   send/receive Info Packages supported.  It is typically up to local-
   policy to determine how to handle such situations, however it should 
   be clear that an INFO request does not itself fork, since it uses 
   the dialog identifiers and follows [RFC3261] and thus follows the 
   path to a specific fork. 
    
6.2. Detecting support for INFO and Info Packages 
    
   INFO does not necessitate the use of "Require" or "Proxy-Require" 
   headers; similarly, there is no token defined for "Supported" 
   headers.  If necessary, clients may probe for the support of INFO 
   using the OPTIONS request defined in SIP [RFC3261]. 
    
   The presence of the "Send-Info" or "Recv-Info" header in a message 
   is sufficient to indicate support for INFO. 
    
      The "methods" parameter for Contact may also be used to 
      specifically announce support for INFO messages when  
      registering. (See [CALLER-PREFS] for details on the "methods" 
      parameter). 
    
   For Info Packages, this draft does not provide a means of requiring 
   support for a specific Info Package.  If the far-end UA does not 
   indicate support for an Info Package that the local server requires, 
   the server MAY terminate the session with a CANCEL or BYE request. 
   [TBD: do we need a Require option-tag or similar mechanism?] 
    
7. Legacy Uses of INFO 
    
   Several RFC-defined and other standards-defined uses of [RFC2976] 
   INFO exist and are in use, as well as numerous proprietary uses.  By 
   definition, such uses have relied on either static local 
   configuration, or implicit context determination based on the body 
   Content-Type or Content-Disposition value, or some proprietary 
   mechanism.  This draft cannot forbid nor avoid such uses, since 
   local configuration can always override standardized mechanisms.   
    
   To maintain backward compatibility with the standardized uses of 
   INFO, a server MAY interpret an INFO request with no "Info-Package" 
   header as being of such legacy use. [TBD: what response if not 
   supported?] 
    
   It should be noted that such legacy use will not "break" the 
   mechanism in this draft.  For example, if a UA supports [SIP-T] use 
 
 
Kaplan, et al.         Expires - August 2008               [Page 11]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   previously, it did so based on static local configuration or based 
   on acceptance of the application/isup body.  If it adds support for 
   this draft's Info Package negotiation mechanism, the local 
   configuration would still apply, and the UA will send/receive INFO 
   messages based on [SIP-T] regardless of the Info Package 
   negotiation.  It will also be able to send/receive INFO messages 
   based on the Info Packages it negotiated.  If, at some future time, 
   an Info Package is defined for [SIP-T], the UA can indicate such in 
   the negotiation, and again local configuration would supersede if 
   need be.  The UA would not lose the ability to use [SIP-T] with 
   legacy devices - it would gain the ability to use it with devices 
   which support this draft and with which it did not have such local 
   configuration set, and could avoid failures related to unsupported 
   bodies. 
    
   It is the hope of this draft's authors that vendors which implement 
   proprietary INFO uses submit their mechanisms as Info Package 
   extension documents, and follow the Info Package negotiation 
   mechanism defined in this draft. 
    
8. Info Packages 
    
   This section covers several issues which should be taken into 
   consideration when new Info Packages are proposed. 
    
8.1. Appropriateness of Usage 
    
   When designing an Info Package using the method described in this 
   document for information exchange, it is important to consider: is 
   INFO and, more importantly, is signaling within a SIP dialog, an 
   appropriate mechanism for the problem set?  Is it because it is the 
   most reasonable and appropriate choice, or merely because "it's 
   easy"? 
    
   These are difficult issues to consider, especially when presented 
   with real-world deadlines and implementation cost issues.  However, 
   choosing to use INFO for inappropriate uses *will* lead to issues in 
   the real world, not the least of which are certain types of 
   middleboxes which will remove the device from the network if it is 
   found to cause damage to other SIP nodes. 
    
   Therefore, the following sections try to provide consideration 
   guidelines and alternatives to INFO use. 
    
8.1.1     Dialog Fate-Sharing 
    
   INFO, by design, is a method within an INVITE dialog usage.  
   [RFC5057] enumerates the problems with using dialogs for multiple 
   usages, and we strongly urge the reader to review RFC 5057.  The 
 
 
Kaplan, et al.         Expires - August 2008               [Page 12]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   most relevant issue is a failure of transmission or processing of an 
   INFO may render the INVITE dialog terminated, depending on the type 
   of failure.  Prior to [RFC5057] it was underspecified if the INFO 
   usage was a separate usage or not.  However, RFC 5057 clarifies the 
   INFO method is always part of the INVITE usage. 
    
   Some uses of INFO can tolerate this fate sharing of the INFO message 
   over the entire dialog.  For example, in the SIP-T usage, it may be 
   acceptable for a call to fail, or to tear down the call, if one 
   cannot deliver the associated SS7 information; likewise for DTMF.  
   However, it may not be acceptable for a call to fail if, for 
   example, a DTMF buffer overflows.  Then again, for some services, 
   that may be the exact desired behavior.   
    
8.1.2     Messaging Rates and Volume 
    
   There is no throttling mechanism for INFO.  Consider that most call 
   signaling occurs on the order of 7-10 messages per 3 minutes, 
   although with a burst of 5-7 messages in one second.  DTMF tones 
   occur in bursts at a rate of up to 20 messages per second.  This is 
   a considerably higher rate than for call signaling, but at least it 
   is infrequent in nature during the duration of a call.  Sending 
   constant GPS location updates, on the other hand, would incur an 
   undue burden on SIP Proxies along the path. 
    
   Furthermore, SIP messages tend to be relatively small, on the order 
   of 500 Bytes to 32K Bytes.  SIP is a poor mechanism for direct 
   exchange of bulk data beyond these limits, which is more appropriate 
   for [MSRP], [COMEDIA], or HTTP.   
    
8.1.3     Proxy-path Signaling 
    
   Using INFO means all Record-Routing proxies, and B2BUA's, in the 
   path between the UA's will receive the INFO messages.  For some 
   applications, such as DTMF, this may be desirable, while for others 
   this may have no benefit whatsoever.  If there is no benefit, then 
   it is imposing unnecessary processing burden on the proxies.  In 
   addition, User Agents may have a need for a relatively low-latency 
   exchange of messages.  In this latter case, the User Agent may not 
   be able to tolerate the latency introduced by intermediate proxies.  
   Likewise, the intermediate proxies may have no interest in 
   processing all of that data. 
    
8.1.4     Is there a better alternative? 
    
   The design goal of the SUBSCRIBE/NOTIFY [RFC3265] event framework is 
   to meet the general need of periodic state notifications/updates.  
   Subscribes have their own dialog or usage, and thus can outlive an 

 
 
Kaplan, et al.         Expires - August 2008               [Page 13]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   INVITE one, but they can also follow the path of the INVITE-based 
   dialog. 
    
   The MESSAGE method in [RFC3428] was defined for one-time instant 
   message exchange, typically for sending MIME contents which should 
   be rendered to the user.   
    
   [MSRP] was created for session-based instant messaging, as well as 
   bulk file transfer, and other such large-volume uses.  It is part of 
   an INVITE-based session, similar to other media.  Unlike INFO, it 
   follows a more direct media-plan path, rather than the SIP signaling 
   one. 
    
8.2. Info Package Responsibilities 
    
   Info packages are not required to reiterate any of the behavior 
   described in this document, although they may choose to do so for 
   clarity or emphasis.  In general, though, such packages are expected 
   to describe only the behavior that extends or modifies the behavior 
   described in this document. 
    
   Note that any behavior designated with "SHOULD" or "MUST" in this 
   document is not allowed to be weakened by extension documents; 
   however, such documents may elect to strengthen "SHOULD" 
   requirements to "MUST" strength if required by their application. 
    
   In addition to the normal sections expected in standards-track RFCs 
   and SIP extension documents, authors of Info Packages need to 
   address each of the issues detailed in the following subsections, 
   whenever applicable. 
    
8.2.1     Info Package Name 
    
   This section, which MUST be present, defines the token name to be 
   used to designate the Info Package.  It MUST include the information 
   which appears in the IANA registration of the token.  For 
   information on registering such types, see section 12. 
    
8.2.2     Info Package Parameters 
    
   If parameters are to be used on the "Info-Package" header to modify 
   the behavior of the Info Package, the syntax and semantics of such 
   parameters MUST be clearly defined. 
    
8.2.3     INFO Bodies 
    
   Each Info Package MUST define what type or types of bodies are 
   expected in INFO requests.  Such packages MUST specify or cite 

 
 
Kaplan, et al.         Expires - August 2008               [Page 14]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   detailed specifications for the syntax and semantics associated with 
   such a body. 
    
   Info Packages also MUST define which MIME type is to be assumed if 
   none are specified in the "Accept" header of the INVITE request. 
    
8.2.4     UA generation of INFO requests 
    
   This section of an Info Package describes the process by which a UA 
   generates and sends an INFO request.  This includes detailed 
   information about what events cause INFO to be sent.  Such a section 
   is required. 
    
   This section may optionally describe the behavior used to process 
   the subsequent response. 
    
8.2.5     UA processing of INFO requests 
    
   This section of an Info Package describes the process followed by 
   the UA upon receipt of an INFO request. 
    
8.2.6     Rate of notifications 
    
   Each Info Package is expected to define a requirement (SHOULD or 
   MUST strength) which defines an absolute maximum on the rate at 
   which INFO messages are allowed to be generated for the package by a 
   UA in a dialog. 
    
   Each package MAY further define a throttle mechanism which allows 
   UAs to further limit the rate of INFO messages. 
    
8.2.7     Examples 
    
   Info Packages SHOULD include several demonstrative message flow 
   diagrams paired with several typical, syntactically correct, and 
   complete messages. 
   It is RECOMMENDED that documents describing Info Packages clearly 
   indicate that such examples are informative and not normative, with 
   instructions that implementers refer to the main text of the 
   document for exact protocol details. 
    
    
9. Syntax 
    
   This section describes the syntax extensions required for event 
   notification in SIP.  Semantics are described in previous sections.  
   Note that the formal syntax definitions described in this document 
   are expressed in the ABNF format used in SIP [RFC3261], and contain 
   references to elements defined therein. 
 
 
Kaplan, et al.         Expires - August 2008               [Page 15]
                The SIP INFO Method and Info Packages   February 2008 
 
 
    
9.1. New Method 
    
   This document describes one new SIP method: INFO. 
   This table expands on tables 2 and 3 in SIP [RFC3261]. 
    
     Header                    Where    INFO 
     ------                    -----    ---- 
     Accept                      R       o 
     Accept-Encoding             R       o 
     Accept-Language             R       o 
     Allow                      200      - 
     Allow                      405      o 
     Authorization               R       o 
     Call-ID                    gc       m 
     Contact                     R       o 
     Contact                    1xx      - 
     Contact                    2xx      - 
     Contact                    3xx      - 
     Contact                    485      - 
     Content-Encoding            e       o 
     Content-Length              e       o 
     Content-Type                e       * 
     CSeq                       gc       m 
     Date                        g       o 
     Encryption                  g       o 
     Expires                     g       o 
     From                       gc       m 
     Hide                        R       o 
     Max-Forwards                R       o 
     Organization                g       o 
     Priority                    R       o 
     Proxy-Authenticate         407      o 
     Proxy-Authorization         R       o 
     Proxy-Require               R       o 
     Require                     R       o 
     Retry-After                 R       - 
     Retry-After            404,480,486  o 
     Retry-After                503      o 
     Retry-After              600,603    o 
     Response-Key                R       o 
     Record-Route                R       o 
     Record-Route               2xx      o 
     Route                       R       o 
     Server                      r       o 
     Subject                     R       o 
     Timestamp                   g       o 
     To                        gc(1)     m 

 
 
Kaplan, et al.         Expires - August 2008               [Page 16]
                The SIP INFO Method and Info Packages   February 2008 
 
 
     Unsupported                420      o 
     User-Agent                  g       o 
     Via                       gc(2)     m 
     Warning                     r       o 
     WWW-Authenticate           401      o 
    
     Table 1 Summary of header fields 
    
9.1.1     INFO Method 
    
   "INFO" is added to the definition of the element "Method" in the SIP 
   message grammar. 
    
   Like all SIP method names, the INFO method name is case sensitive.  
   The INFO method is used to transmit session-related information 
   within an INVITE-based dialog. 
    
9.2. New Headers 
    
   This table expands on tables 2 and 3 in SIP [RFC3261]. 
    
   [Should the new header fields be optional for OPTIONS and REGISTER?  
   TBD by SIP-WG] 
    
   Header field where   ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT 
   -------------------------------------------------------------------- 
   Info-Package   R      -   -   -   -   -   -   -   m   -   -   -   - 
   Info-Package   r      -   -   -   -   -   -   -   o   -   -   -   - 
   Send-Info      R      -   -   -   o   -   o   -   -   -   -   -   - 
   Send-Info      2xx    -   -   -   o   o   -   -   -   -   -   -   - 
   Send-Info      1xx    -   -   -   o   o   -   -   -   -   -   -   - 
   Send-Info      r      -   -   -   -   o   -   -   -   -   -   -   - 
   Recv-Info      R      -   -   -   o   -   o   -   -   -   -   -   - 
   Recv-Info      2xx    -   -   -   o   o   -   -   -   -   -   -   - 
   Recv-Info      1xx    -   -   -   o   o   -   -   -   -   -   -   - 
   Recv-Info      r      -   -   -   -   o   -   -   -   -   -   -   - 
    
 
    
9.2.1     "Info-Package" header 
    
   Info-Package is added to the definition of the element "message-
   header" in the SIP message grammar. 
    
   For the purposes of matching Info Package types indicated in Send-
   Info or Recv-Info with those in the Info-Package header field value, 
   the Info-package-name portion of the Info-package-type portion of 
   the "Info-Package" header is compared byte-by-byte with that of the 

 
 
Kaplan, et al.         Expires - August 2008               [Page 17]
                The SIP INFO Method and Info Packages   February 2008 
 
 
   same in the "Send-Info" or "Recv-Info" header values.  In other 
   words, the Info-package-param is not used for comparison checking. 
    
   This document does not define values for Info-Package-types.  These 
   values will be defined by individual Info Packages, and MUST be 
   registered with the IANA. 
    
   There MUST be exactly one Info Package type listed per Info-Package 
   header. Multiple Info-Packages per INFO message are disallowed. 
    
9.2.2     "Send-Info" header  
    
   Send-Info is added to the definition of the element "general-header" 
   in the SIP [RFC3261] message grammar.  Its usage is described in 
   section 5. 
    
9.2.3     "Recv-Info" header 
    
   Recv-Info is added to the definition of the element "general-header" 
   in the SIP [RFC3261] message grammar.  Its usage is described in 
   section 5. 
    
9.3. Augmented BNF Definitions 
    
   The Augmented BNF definitions for the various new and modified 
   syntax elements follows.  The notation is as used in SIP [RFC3261], 
   and any elements not defined in this section are as defined in SIP 
   and the documents to which it refers. 
    
   INFOm               = %x49.4E.46.4F ; INFO in caps 
   extension-method    = INFOm / token 
    
   Info-Package        =  "Info-Package" HCOLON Info-package-type 
   Send-Info           =  "Send-Info" HCOLON Info-package-type 
                          *( COMMA Info-package-type ) 
   Recv-Info           =  "Send-Info" HCOLON Info-package-type 
                          *( COMMA Info-package-type ) 
   Info-package-type   =  Info-package-name *( "." Info-package-param) 
   Info-package-name   =  token-nodot 
   token-nodot         =  1*( alphanum / "-"  / "!" / "%" / "*" 
                              / "_" / "+" / "`" / "'" / "~" ) ;rfc3265 
   Info-package-param  =  generic-param  ;this doesn't work due to dot! 
    
    





 
 
Kaplan, et al.         Expires - August 2008               [Page 18]
                The SIP INFO Method and Info Packages   February 2008 
 
 
10.  Example Exchange 
 
   In the following example, Alice initiates a call to Bob.  Alice can 
   support sending or receiving "foo" Info Packages, and sending "bar" 
   Info Packages. 
    
   Alice generates the following: (note: much has been left out for 
   simplicity) 
      INVITE sip:bob@example.com SIP/2.0 
      Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 
      From: Alice <sip:alice@example.net>;tag=1234567 
      To: Bob <sip:bob@example.com> 
      Call-Id: 123456mcmxcix 
      CSeq: 1 INVITE 
      Contact: <sip:alice@192.0.2.1> 
      Send-Info: foo, bar 
      Recv-Info: foo 
    
   Bob checks the header field values, can support sending but not 
   receiving "foo", and sending but not receiving "bar".  Note that 
   since Bob does not support receiving anything Alice can send, the 
   response does not list any Recv-Info packages. 
    
      SIP/2.0 180 Ringing 
      Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 
      From: Alice <sip:alice@example.net>;tag=1234567 
      To: Bob <sip:bob@example.com>;tag=abcdefg 
      Call-Id: 123456mcmxcix 
      CSeq: 1 INVITE 
      Send-Info: foo 
    
   Since he sent the Send-Info header field value in the 180, and still 
   wishes to support it, Bob also sends it in the 200 response. 
    
      SIP/2.0 200 OK 
      Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10 
      From: Alice <sip:alice@example.net>;tag=1234567 
      To: Bob <sip:bob@example.com>;tag=abcdefg 
      Call-Id: 123456mcmxcix 
      CSeq: 1 INVITE 
      Contact: <sip:bob@192.0.2.2> 
      Send-Info: foo 
    
   Alice can send an Info Package as soon as she received the 180, but 
   in this example she would not have been able to do so since Bob 
   didn't say he could receive any Info Packages in his 180 response.  
   Bob must wait to receive the ACK before sending any "foo" packages 
   (ACK not shown), at which point he sends the following: 

 
 
Kaplan, et al.         Expires - August 2008               [Page 19]
                The SIP INFO Method and Info Packages   February 2008 
 
 
    
      INFO sip:alice@192.0.2.1 SIP/2.0 
      Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef 
      To: Alice <sip:alice@example.net>;tag=1234567 
      From: Bob <sip:bob@example.com>;tag=abcdefg 
      Call-Id: 123456mcmxcix 
      CSeq: 2 INFO 
      Contact: <sip:bob@192.0.2.2> 
      Info-Package: foo 
    
    
11.  Security Considerations 
    
   There are no specific security issues for this mechanism, beyond 
   those already applicable to SIP-based session signaling.  In 
   particular, if the SIP signaling is not protected from 
   eavesdropping, authentication and repudiation, for example by using 
   TLS transport, then the INFO request and its contents will not be 
   protected either.  Even with SIP/TLS, any SIP hop along the path 
   from UAC to UAS can view, modify, or intercept INFO requests, as 
   they can any SIP request. 
    
   One interesting property of Info Package use is that the same 
   digest-challenge mechanism used for INVITE-based authentication can 
   be reused for the INFO request.  For example one could use a 
   quality-of-protection (qop) value of authentication with integrity 
   (auth-int), to challenge the request and its body, and prevent 
   intermediate devices from modifying the body.  However this assumes 
   the device which knows the credentials in order to perform the 
   INVITE challenge is still in the path for the INFO, or that the far-
   end UAS knows such credentials. 
    
12.  IANA Considerations 
    
   This document will define an Info Package-type namespace, the 
   specifics of which are TBD.  Should this draft move forward, the 
   body chosen for this coordination would be the Internet Assigned 
   Numbers Authority (IANA). 
    
13.  Acknowledgements 
    
   The authors wish to thank Brian Stucker, Francois Audet, Paul 
   Kyzivat, Adam Roach, Eric Burger, and Robert Sparks for their 
   suggestions and comments; and for Dean Willis, who was ahead of his 
   time, having submitted a similar draft 5 years ago.  Special thanks 
   goes to Adam Roach for writing [RFC3265], from which several 
   sections of text were directly copied into this draft. 


 
 
Kaplan, et al.         Expires - August 2008               [Page 20]
                The SIP INFO Method and Info Packages   February 2008 
 
 
    
14.  References 
    
14.1.     Normative References 
    
   [RFC2976]  Donovan, S., "The SIP INFO Method", RFC 2976, October 
   2000. 
    
   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 
   A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:  
   Session Initiation Protocol", RFC 3261, June 2002. 
     
    
14.2.     Informative References 
    
   [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 
   Event Notification", RFC 3265, June 2002 
    
   [SIP-T] Vemuri, A., Peterson, J., "Session Initiation Protocol for 
             Telephones (SIP-T): Context and Architectures", RFC 3372, 
             September 2002. 
 
   [RFC3428] Campbell, B., et al, "Session Initiation Protocol (SIP) 
             Extension for Instant Messaging", RFC 3428, December 2002. 
    
   [CALLER-PREFS] Rosenberg, J., Schulzrinne, H., Kyzivat, P., "Caller 
             Preferences for the Session Initiation Protocol (SIP)", 
             RFC 3841, August 2004. 
    
   [RFC4028] Donavan, S., Rosenberg, J., "Session Timers in the Session 
   Initiation Protocol (SIP)", RFC 4028, April 2005. 
    
   [COMEDIA] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 
   the Session Description Protocol (SDP)", RFC 4145, September 2005. 
    
   [MSRP] Campbell, B., Mahy, R., Jennings, C., "The Message Session 
   Relay Protocol (MSRP)", RFC 4975, September 2007. 
    
   [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 
   Initiation Protocol", RFC 5057, February 2007 
    
   [info-harmful] Burger, E., "Session Initiation Protocol (SIP) INFO 
             Method Use", draft-burger-sip-info-02.txt, November 2007. 
    
    




 
 
Kaplan, et al.         Expires - August 2008               [Page 21]
                The SIP INFO Method and Info Packages   February 2008 


Authors' Addresses

   Hadriel Kaplan 
   Acme Packet 
   71 Third Ave. 
   Burlington, MA 01803
   USA 
   
   Email: hkaplan@acmepacket.com 


   Christer Holmberg 
   Ericsson 
   Hirsalantie 11 
   Jorvas  02420 
   Finland 
   
   Email: christer.holmberg@ericsson.com 
 

   Eric W. Burger 
   BEA Systems, Inc. 
   USA 
   
   Email: eburger@standardstrack.com 






















 
 
Kaplan, et al.         Expires - August 2008               [Page 22]
                The SIP INFO Method and Info Packages   February 2008 
 
 
 
Full Copyright Statement 
    
   Copyright (C) The IETF Trust (2008). 
    
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
    
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE. 


Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org. 
    
    
Acknowledgment 
    
   Funding for the RFC Editor function is provided by the IETF 
   Administrative Support Activity (IASA). 
    

 
 
Kaplan, et al.         Expires - August 2008               [Page 23]