Network Working Group Richard Ejzak INTERNET-DRAFT Lucent Technologies June 16, 2006 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media 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 document is a submission of the IETF AVT WG. Comments should be directed to the AVT WG mailing list, avt@ietf.org. Abstract This document describes a private Session Initiation Protocol (SIP) header (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. Ejzak [Page 1] INTERNET-DRAFT P-Early-Media Header June 16, 2006 Table of Contents 1. Introduction....................................................2 2. Applicability Statement.........................................3 3. Conventions and Acronyms........................................3 4. Background on early media authorization.........................4 4.1. Backward early media.......................................4 4.2. Forward early media........................................5 5. Applicability of RFC 3959 and RFC 3960..........................6 6. Overview of Operation...........................................6 7. Limitations of the P-Early-Media header.........................7 8. The P-Early-Media header........................................8 8.1. Procedures at the User Agent Client........................9 8.2. Procedures at the User Agent Server........................9 8.3. Procedures at the proxy...................................10 9. Formal syntax..................................................10 10. Security Considerations.......................................10 11. IANA Considerations...........................................11 11.1. Registration of the "P-Early-Media" SIP header...........11 12. Acknowledgements..............................................11 13. References....................................................11 13.1. Normative References.....................................11 13.2. Informative References...................................12 14. Authors' Addresses............................................12 15. IPR Notice....................................................12 16. Copyright Notice..............................................13 1. Introduction This document defines the use of the P-Early-Media header for use within SIP [1] messages in certain SIP networks to authorize the cut-through of backward and/or forward early media. The P-Early- Media header is intended for use in a SIP network, such as a 3GPP IMS, that prohibits the exchange of early media between end users, that is interconnected with other SIP networks that have unknown, untrusted or different policies regarding early media, and that has the capability to "gate" (enable/disable) the flow of early media to/from user equipment. Within an isolated SIP network it is possible to gate early media associated with all endpoints within the network to enforce a desired early media policy among network endpoints. However, when a SIP network is interconnected with other SIP networks, only the boundary node connected to the external network can determine which early media policy to apply to a session established between endpoints on different sides of the boundary. The P-Early-Media header provides a means for this boundary node to communicate this early media policy decision to other nodes within the network. Ejzak [Page 2] INTERNET-DRAFT P-Early-Media Header June 16, 2006 2. Applicability Statement The use of this extension is only applicable inside a 'Trust Domain' as defined in RFC 3325 [9]. Nodes in such a Trust Domain are explicitly trusted by its users and end-systems to authorize early media requests only when allowed by early media policy within the Trust Domain. This document does NOT offer a general early media authorization model suitable for inter-domain use or use in the Internet at large. Furthermore, since the early media requests are not cryptographically certified, they are subject to forgery, replay, and falsification in any architecture that does not meet the requirements of the Trust Domain. An early media request also lacks an indication of whom specifically is making or modifying the request, and so it must be assumed that the Trust Domain is making the request. Therefore, the information is only meaningful when securely received from a node known to be a member of the Trust Domain. Although this extension can be used with parallel forking, it does not improve on the known problems with early media and parallel forking. Despite these limitations, there are sufficiently useful specialized deployments that meet the assumptions described above, and can accept the limitations that result, to warrant publication of this mechanism. An example deployment would be a closed network that emulates a traditional circuit switched telephone network. 3. Conventions and Acronyms 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 RFC2119 [1]. The following acronyms are used in this document: 3GPP - the Third Generation Partnership Project ABNF - Augmented Backus-Naur Form DTMF - Dual Tone Multi-Frequency ETSI - European Telecommunications Standards Institute IMS - Internet Protocol Multimedia Subsystem MIME - Multipurpose Internet Mail Extensions NAT - Network Address Translation PSTN - Public Switched Telephone Network SDP - Session Description Protocol SIP - Session Initiation Protocol Ejzak [Page 3] INTERNET-DRAFT P-Early-Media Header June 16, 2006 TISPAN - Telecommunications and Internet converged Services and Protocols for Advanced Networks UA - User Agent UAC - User Agent Client UAS - User Agent Server 4. Background on early media authorization PSTN networks typically provide call progress information as backward early media from the terminating switch towards the calling party. In a SIP network, backward early media flows from the User Agent Server (UAS) towards the User Agent Client (UAC). PSTN networks also use forward early media from the calling party towards the terminating switch under some circumstances for applications such as digit collection for secondary dialing. In a SIP network, forward early media flows from the UAC towards the UAS. PSTN networks typically allow backward and/or forward early media since they are used for the purpose of progressing the call to the answer state and do not involve the exchange of data between endpoints. On the other hand, a SIP network may have a policy to prohibit backward early media from SIP user equipment and to prohibit forward media towards SIP user equipment, either of which may contain user data. A SIP network containing both PSTN gateways and SIP end devices, for example, can maintain such an early media policy by gating off any early media with a SIP end device acting as UAS, gating on early media with a SIP end device acting as UAC, and appropriately gating early media at each PSTN gateway. Unfortunately, a SIP network interconnected with another SIP network may have no means of assuring that the interconnected network is implementing a compatible early media policy. Without this extension, a SIP network interconnected with other SIP networks provides no mechanism for an originating SIP endpoint within the network, be it a PSTN gateway or SIP user equipment, from identifying if the terminating SIP endpoint, which may be located outside the network, is a SIP endpoint that is authorized either to send backward early media or to receive forward early media. 4.1. Backward early media Backward early media in the PSTN typically comprises call progress information such as ringing, or announcements regarding special handling such as forwarding. It may also include requests for further information, such as a credit card number to be entered as forward early media in the form of Dual Tone Multi-Frequency (DTMF) tones or speech. Backward early media of this type provides information to the calling party strictly for the purpose of progressing the call and involves no exchange of data between end Ejzak [Page 4] INTERNET-DRAFT P-Early-Media Header June 16, 2006 users. The usual PSTN charging policy assumes that no data is exchanged between users until the call has been answered. A terminating SIP User Agent (UA) outside of the SIP network, on the other hand, may provide any user data in a backward early media stream. Thus if the network implements the usual early media policy, the network equipment gating the backward early media flow for the originating UA must distinguish between authorized early media from a terminating SIP endpoint and unauthorized early media from another SIP device outside of the network. Given the assumption of a transitive trust relationship between SIP servers in the network, this can be accomplished by including some information in a backward SIP message that identifies the presence of authorized backward early media. Since it is necessary to verify that this indication comes from a trusted source, it is necessary for each server on the path back to the originating UA be able to verify the trust relationship with the previous server and to remove such an indication when it cannot do so. A server on the boundary to an untrusted SIP network can assure that no indication of authorized backward early media passes from an external UAS to a UAC within the network. Thus the use of a private header that can be modified by SIP proxies is to be preferred over the use of a Multipurpose Internet Mail Extensions (MIME) attachment that cannot be modified in this way. 4.2. Forward early media Forward early media is less common than backward early media in the PSTN. It is typically used to collect secondary dialed digits, to collect credit card numbers, or to collect other DTMF or speech responses for the purpose of further directing the call. Forward early media in the PSTN is always directed toward a network server for the purpose of progressing a call and involves no exchange of data between end users. A terminating SIP UA outside of the SIP network, on the other hand, may receive any user data in a forward early media stream, thus if the network implements the usual early media policy, the network equipment gating the forward early media flow for the originating UA must distinguish between a terminating endpoint that is authorized to receive forward early media, and another SIP device outside of the network that is not authorized to receive forward early media containing user data. This authorization can be accomplished in the same manner as for backward early media by including some information in a backward SIP message that identifies that the terminating side is authorized to receive forward early media. Ejzak [Page 5] INTERNET-DRAFT P-Early-Media Header June 16, 2006 5. Applicability of RFC 3959 and RFC 3960 The private header extension defined in this document is applicable to the gateway model defined in RFC 3960 [7], since the PSTN gateway is the primary requestor of early media in an IMS. For the same reason, neither the application server model of RFC 3960, nor the early-session disposition type defined in RFC 3959 [6] is applicable. The gateway model of RFC 3960 [7] allows for individual networks to create local policy with respect to the handling of early media, but does not address the case where a network is interconnected with other networks with unknown, untrusted or different early media policies. Without the kind of information in the P-Early-Media header, it is not possible for the network to determine whether cut- through of early media could lead to the transfer of data between end-users during session establishment. Thus the private header extension in this document is a natural extension of the gateway model of RFC 3960 [7] that is applicable within a transitive trust domain. 6. Overview of Operation This document defines a new P-Early-Media header field for the purpose of requesting and authorizing requests for backward and/or forward early media. A UAC capable of recognizing the P-Early-Media header may include the header in an INVITE request. The P-Early- Media header in an INVITE request contains no parameters. As members of the Trust Domain, each proxy receiving an INVITE request must decide whether to insert or modify the P-Early-Media header before forwarding. A UAS receiving an INVITE request can use the presence of the P- Early-Media header in the request to decide whether to request early media authorization in subsequent messages towards the UAC. After receiving an incoming INVITE request, the UAS requesting backward and/or forward early media will include the P-Early-Media header in a 18X provisional response or an UPDATE request within the dialog, including direction parameter(s) that identify for each media line in the session whether the early media request is for backward media, forward media, both or neither. The UAS can change its request for early media by including a modified P-Early-Media header in a subsequent 18X provisional response or UPDATE request within the dialog. Each proxy in the network receiving the P-Early-Media header in a message towards the UAC has the responsibility for assuring that the early media request comes from an authorized source. If a P-Early- Ejzak [Page 6] INTERNET-DRAFT P-Early-Media Header June 16, 2006 Media header arrives from either an untrusted source, a source not allowed to send backward early media, or a source not allowed to receive forward early media, then the proxy may remove the P-Early- Media header or alter the direction parameter(s) of the P-Early- Media header before forwarding the message, based on local policy. If the proxy also performs gating of early media, then it uses the direction parameter of the P-Early-Media header to gate on/off backward and/or forward early media flow between the UAs. If the UAC is a trusted server within the network (e.g., a PSTN gateway), then the UAC may use the direction parameter of the P- Early-Media header in the 18X provisional response to perform early media gating or cut-through and to decide whether or not to render backward early media in preference to generating ringback based on the receipt of a 180 Ringing response. If the UAC is associated with user equipment, then the network will have assigned a proxy the task of performing early media gating, so that the direction parameter of the P-Early-Media header received at such a UAC does not police the early media flow, but does provide additional information that the UAC may use to render media. 7. Limitations of the P-Early-Media header The P-Early-Media header does not apply to any SDP with Content- Disposition: early-session [6] and SHOULD NOT be included in any message toward a UAC in a dialog in which early-session media is being used. When parallel forking occurs, there is no reliable way to correlate early media authorization in a dialog with the media from the corresponding endpoint, since the SDP messages do not identify the RTP source address of any media stream. When a UAC or proxy receives multiple early dialogs, it SHOULD use the most restrictive early media authorization it receives on any of the dialogs to decide the policy to apply towards all received media. When early media usage is desired for any reason it is advisable to disable parallel forking using callerprefs [14]. Although the implementation of media gating is outside the scope of this extension, note that media gating must be implemented carefully in the presence of NATs and protocols that aid in NAT traversal. Media gating may also introduce a potential for media clipping that is similar to that created during parallel forking or any other feature that may disable early media, such as custom ringback. Ejzak [Page 7] INTERNET-DRAFT P-Early-Media Header June 16, 2006 8. The P-Early-Media header The P-Early-Media header with no parameters MAY be included in an INVITE request to indicate that the UAC or a proxy on the path recognizes the header. The P-Early-Media header MAY be included in any 18X provisional response to the INVITE request, or within an UPDATE request towards the sender of the INVITE request, for the purpose of requesting the authorization of early media. The P-Early-Media header includes one or more parameters where each has one of the values: "sendrecv", "sendonly", "recvonly", or "inactive", following the convention used for Session Description Protocol (SDP) [10] stream directionality. Each parameter applies, in order, to the media lines in the corresponding SDP messages establishing session media. Unrecognized parameters SHALL be silently discarded. If there are more parameters than media lines, the excess SHALL be silently discarded. If there are fewer parameters than media lines, the value of the last parameter SHALL apply to all remaining media lines. A message directed towards the UAC containing a P-Early-Media header with no recognized parameters SHALL NOT be interpreted as an early media authorization request. The parameter value "sendrecv" indicates a request for authorization of early media associated with the corresponding media line, both from the UAS towards the UAC and from the UAC towards the UAS (both backward and forward early media). The value "sendonly" indicates a request for authorization of early media from the UAS towards the UAC (backward early media), and not in the other direction. The value "recvonly" indicates a request for authorization of early media from the UAC towards the UAS (forward early media), and not in the other direction. The value "inactive" indicates either a request that no early media associated with the corresponding media line be authorized, or a request for revocation of authorization of previously authorized early media. When receiving a message directed toward the UAC without the P- Early-Media header and no previous early media authorization request has been received within the dialog, the default early media authorization depends on local policy and may depend on whether the header was included in the INVITE request. After an early media authorization request has been received within a dialog and a subsequent message is received without the P-Early-Media header, the previous early media authorization remains unchanged. The P-Early-Media header does not interact with SDP offer/answer procedures in any way. Early media authorization is not influenced by the state of the SDP offer/answer procedures (including preconditions and directionality) and does not influence the state of the SDP offer/answer procedures. The P-Early-Media header may or may not be present in messages containing SDP. The most recently Ejzak [Page 8] INTERNET-DRAFT P-Early-Media Header June 16, 2006 received early media authorization applies to the corresponding media line in the session established for the dialog until receipt of the 200 OK response to the INVITE request, at which point all media lines in the session are implicitly authorized. Early media flow in a particular direction requires that early media in that direction is authorized, that media flow in that direction is enabled by the SDP direction attribute for the stream, and that any applicable preconditions [16] are met. Early media authorization does not override the SDP direction attribute or preconditions state, and the SDP direction attribute does not override early media authorization. Table 1 is an extension of Tables 2 and 3 in RFC 3261 [1] for the P- Early-Media header field. The column "UPD" is for the UPDATE method [15]. Header field where proxy ACK BYE CAN INV OPT REG UPD ____________________________________________________________ P-Early-Media R amr - - - o - - o P-Early-Media 18x amr - - - o - - - Table 1: P-Early-Media Header Field 8.1. Procedures at the User Agent Client A User Agent Client MAY include the P-Early-Media header with no parameters in an INVITE request to indicate that it recognizes the header. A User Agent Client receiving a P-Early-Media header MAY use the direction parameter(s) of the header to gate or cut-through early media, and to decide whether to render early media from the UAS to the UAC in preference to any locally generated ringback triggered by a 180 Ringing response. If a proxy is providing the early media gating function for the User Agent Client, then the gateway model of RFC 3960 [7] for rendering of early media is applicable. A User Agent Client without a proxy in the network performing early media gating that receives a P-Early-Media header SHOULD perform gating or cut-through of early media according to the direction parameter(s) of the header. 8.2. Procedures at the User Agent Server A User Agent Server that is requesting authorization to send or receive early media MAY insert a P-Early-Media header with appropriate direction value(s) in any 18X provisional response to the INVITE request or in any UPDATE request within the dialog. A User Agent Server MAY request changes in early media authorization Ejzak [Page 9] INTERNET-DRAFT P-Early-Media Header June 16, 2006 by inserting a P-Early-Media header with appropriate direction value in any subsequent 18X provisional response or UPDATE request. If the P-Early-Media header is not present in the INVITE request, the User Agent Server MAY choose to suppress early media authorization requests and MAY choose to execute alternate early media procedures. 8.3. Procedures at the proxy When forwarding an INVITE request, a proxy MAY add, retain or delete the P-Early-Media header, depending on local policy and the trust relationship with the sender and/or receiver of the request. When forwarding an 18x provisional response to an INVITE request or forwarding an UPDATE request towards the User Agent Client, a proxy MAY add, modify or delete a P-Early-Media header, depending on local policy and the trust relationship with the sender and/or receiver of the message. In addition, if the proxy controls the gating of early media for the User Agent Client, it SHALL use the contents of the P- Early-Media header to gate the early media according to the definition of the direction parameter defined in clause 8. 9. Formal syntax This syntax of the P-Early-Media header is described below in ABNF according to RFC 4234 [8], as an extension to the ABNF for SIP in RFC 3261 [1]. P-Early-Media = "P-Early-Media" HCOLON [ em-param *(COMMA em-param) ] em-param = "sendrecv" / "sendonly" / "recvonly" / "inactive" / token 10. Security Considerations There are no confidentiality concerns associated with the P-Early- Media header. It is desirable to maintain the integrity of the direction parameters in the header across each hop between servers to avoid the potential for unauthorized use of early media. It is assumed that the P-Early-Media header is used within the context of the 3GPP IMS trust domain or a similar trust domain, consisting of a collection of SIP servers maintaining pair wise security associations. In an IMS it is only necessary to police the use of the P-Early-Media header at the boundary to user equipment served by the network and at the boundary to peer networks. It is assumed that boundary servers in the IMS will have local policy for the treatment of the P-Early-Media header as it is sent to or received Ejzak [Page 10] INTERNET-DRAFT P-Early-Media Header June 16, 2006 from any possible server external to the network. Since boundary servers are free to modify or remove any P-Early-Media header in SIP messages forwarded across the boundary, the integrity of the P- Early-Media header can be verified to the extent that the connections to external servers are secured. The authenticity of the P-Early-Media header can only be assured to the extent that the external servers are trusted to police the authenticity of the header. 11. IANA Considerations 11.1. Registration of the "P-Early-Media" SIP header Name of Header: P-Early-Media Short form: none Registrant: Richard Ejzak ejzak@lucent.com Normative description: Section 8 of this document 12. Acknowledgements The author would like to thank Miguel Garcia-Martin, Jan Holm, Sebastien Garcin, Akira Kurokawa, Erick Sasaki, James Calme, Greg Tevonian, Aki Niemi, Paul Kyzivat and Gonzalo Camarillo for their significant contributions made throughout the writing and reviewing of this document. 13. References 13.1. Normative References [1] 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. [2] 3GPP “TS 23.228: IP Multimedia Subsystem (IMS); Stage 2 (Release 7)”, 3GPP 23.228, September 2005, ftp://ftp.3gpp.org/Specs/archive/23-series/23.228/. [3] 3GPP “TS 24.229: IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3 (Release 7)”, 3GPP 24.229, September 2005, ftp://ftp.3gpp.org/Specs/archive/24-series/24.229/. [4] 3GPP “TS 32.200: Telecommunication Management; Charging management; Charging principles (Release 7)”, 3GPP 32.200, September 2005, ftp://ftp.3gpp.org/Specs/archive/32- series/32.200/. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ejzak [Page 11] INTERNET-DRAFT P-Early-Media Header June 16, 2006 [6] Camarillo, G., “The Early Session Disposition Type for the Session Initiation Protocol (SIP)”, RFC 3959, December 2004. [7] Camarillo, G., “Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)”, RFC 3960, December 2004. [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [9] Jennings, C., Peterson, J. and Watson, M., ”Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks”, RFC 3325, November 2002. [10] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 13.2. Informative References [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [13] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [14] Rosenberg, J., Schulzrinne, H. and Kyzivat, P., "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [15] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, September 2002. [16] Camarillo, G., Marshall, W. and Rosenberg, J., "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. ETSI documents can be downloaded from the ETSI web server, http://www.etsi.org/". Any 3GPP document can be downloaded from the 3GPP webserver, "http://www.3gpp.org/", see specifications. 14. Authors' Addresses Richard Ejzak Lucent Technologies 1960 Lucent Lane Naperville, IL 60566, USA Phone: +1 630 979 7036 EMail: ejzak@lucent.com 15. IPR Notice 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 Ejzak [Page 12] INTERNET-DRAFT P-Early-Media Header June 16, 2006 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. 16. Copyright Notice Copyright (C) The Internet Society (2006). 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 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. This Internet-Draft expires in December 2006. RFC Editor Considerations - The RFC editor is requested to replace all occurrences of XXXX with the RFC number this document receives. Ejzak [Page 13]