SIPPING E. Burger Internet-Draft SnowShore Networks, Inc. Expires: August 25, 2003 February 24, 2003 Directed Transcoding draft-burger-sipping-dir-transcode-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 25, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes a mechanism for invoking transcoding services in a SIP network. A user, proxy server, or other agent can transparently request these services, without modification to the existing network. Conventions used in this document This document refers generically to the calling party (caller) in the masculine (he/him/his) and the called party in the feminine (she/her/ hers). This convention is purely for convenience and makes no assumption about the gender of either party. Burger Expires August 25, 2003 [Page 1] Internet-Draft SIP Directed Transcoding February 2003 RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Service Examples . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Inbound SIP Proxy . . . . . . . . . . . . . . . . . . . . . . 4 2.2 On Demand Transcoding: Individual User . . . . . . . . . . . . 5 3. Sample Implementation . . . . . . . . . . . . . . . . . . . . 6 3.1 Using Source-Sink SDP . . . . . . . . . . . . . . . . . . . . 6 3.2 Using Conference Bridge . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Burger Expires August 25, 2003 [Page 2] Internet-Draft SIP Directed Transcoding February 2003 1. Overview There is often a need for transcoding services in a communications network. Common scenarios include transcoding audio real-time data and services for the speech and hearing impaired. Companion papers sip-deaf [9] and source-sink [2] describe the mechanics for transcoding aware devices to request transcoding services from a media server. This document describes a mechanism for creating a pass-through transcoding session. The mechanism described here alleviates the endpoints from needing to understand and execute complex call flows. Moreover, this mechanism is simple for SIP Proxies to implement. The essence of the mechanism is to use a special Request-URI to identify the transcoding service and the target SIP UAS. This is similar to the concept described in netann [10]. The user part (left-hand side) of the Request-URI begins with "xcod=", followed by the target SIP Request-URI, with special characters, like colon (:) and at-sign (@) escaped. The system part (right-hand side) of the Request-URI identifies the transcoding server. Codec negotiation between the UAS, UAC, and transcoding server proceed following standard RFC3261 [3] offer/answer. Optionally, the SDP may contain the source and sink attributes specified in source-sink [2] if the UAC desires multiple simultaneous translations. Burger Expires August 25, 2003 [Page 3] Internet-Draft SIP Directed Transcoding February 2003 2. Service Examples 2.1 Inbound SIP Proxy In this example, a user wishes to have transcoding service performed on her behalf on her inbound sessions. Perhaps they are speech impaired and wish to have the caller hear synthesized speech offered by a transcoding server. To establish the request for the transcoding service, the user registers a special SIP URI for their address. Rather than register the actual address of her UAS, she registers the address of a transcoding server, with her UAS' URI encoded in the registered URI. Figure Figure 1 describes the network components, their relationship, and the SIP Request-URI's formed for each INVITE. +-----------+ +-----+ INVITE sip:target@example.com | target's | | UAC |--------------------------------->| in-bound | +-----+ | SIP Proxy | +-----------+ | INVITE sip:xcod=sip%3areal-target%40example.com@ms.example.com | V +--------------+ | Transcoding | | Server | +--------------+ | +-----+ INVITE real-target@example.com | | UAS |<----------------------------------------+ +-----+ Figure 1 Note the beauty of using opaque SIP Request-URIs. The in-bound SIP Proxy does not need to be aware of the function of the transcoding server. All the in-bound SIP Proxy need do is do a standard lookup for a given SIP Request-URI. In the example above, the SIP Request-URI sip:target@example.com , rather than having the translation sip:real-target@example.com , Burger Expires August 25, 2003 [Page 4] Internet-Draft SIP Directed Transcoding February 2003 has the translation sip:xcod=sip%3areal-target%40example.com@ms.example.com . Said differently, there are absolutely no modifications needed to the SIP Proxy. Considering the use of this method for the subscriber, her callers need never know that she has a transcoding service. For example, the transcoding could be a human reading the subscriber's text. As far as the calling party is concerned, he never knows that he is not speaking with the called party. 2.2 On Demand Transcoding: Individual User In this example, a user wishes to have transcoding service performed on his behalf on a session he initiates. Perhaps they are hearing impaired, he knows that the called party wishes to speak, and he wants to keep his impairment a secret. To establish the request for the transcoding service, the user enters a special SIP URI for the called party's address. Rather than enter the SIP URI of the called party, he enters the address of a transcoding server, with the called party's UAS URI encoded in the SIP Request-URI. Figure bar describes the network components, their relationship, and the SIP Request-URI formed for each INVITE. +-----+ INVITE sip:xcod=sip%3atarget%40example.com@ms.example.com | UAC |---------\ +--------------+ +-----+ \------------------->| Transcoding | | Server | +--------------+ | +-----+ INVITE target@example.com | | UAS |<-------------------------------------+ +-----+ Note again the benefit of using opaque SIP Request-URIs. Not one piece of infrastructure needs modification to support this service. Granted, user's may prefer a smart UAC that automatically generates the transcoding URI from a target URI. However, nothing requires this. On the other hand, this is why it is critically important to standardize the usage of the Request-URI. The standardization enables manufacturers of UAC's and transcoding servers to interoperate. Burger Expires August 25, 2003 [Page 5] Internet-Draft SIP Directed Transcoding February 2003 3. Sample Implementation This section is informative. Any deviations with the preceding sections are unintentional. In the event of deviations, the normative descriptions above are correct. 3.1 Using Source-Sink SDP One can construct a transcoding server from a transcoding application server and media server. o Take the transcoding Request URI and extract the target Request URI o Invite a classical media server to the dialog o Invite the target Request URI, using mechanisms described in sip-deaf [9] Here is a typical network topology. +--------+ INVITE sip:xcod=sip%3atarget%40example.com@t.example.com | UAC or |-------\ +-------------+ | Proxy | \------------------->| Transcoding | +--------+ | App. Server | +-------------+ INVITE target@example.com / | INVITE +-----+ /--------------------/ | xcod@example.com | UAS |<-----/ V +-----+ RTP +--------------+ \==============================| Media Server | +--------------+ Following the example laid out in sip-deaf [9], here is a sample call flow. Burger Expires August 25, 2003 [Page 6] Internet-Draft SIP Directed Transcoding February 2003 C T M S | | | | | INVITE sip:xcod=sip%3atarget%40example.com@t.example.com |------------>| | | (1) | SDP C | | | | | | | | 100 Trying | | | |<------------| | | (2) | | INVITE sip:target@example.com| | |----------------------------->| (3) | | no SDP | | | | | 200 OK | | |<-----------------------------| (4) | | | SDP S | | | | | | | INVITE sip:xcode@ms.example.net | |-------------->| | (5) | | SDP C+S | | | | | | | | 200 OK | | | |<--------------| | (6) | | SDP MC+MS | | | | | | | 200 OK | | | |<------------| | | (7) | SDP MS | | | | | | | | ACK | | | |------------>| ACK | | (8) | |-------------->| | (9) | | ACK | | | |----------------------------->| (10) | | SDP MC | | | | | | | | RTP | RTP | |<===========================>|<============>| (11) | | | | Here is a detailed description of the operation of the mechanism. First, the UAC or Proxy C issues an INVITE to the transcoding application server T with C's SDP in message (1). The transcoding application server T responds with a 100 Trying (2), as it may take some time to coordinate the media server and UAS. The transcoding application server T then invites the UAS S with no SDP in message (3). The UAS S responds with a 200 OK with S's SDP in message (4). Burger Expires August 25, 2003 [Page 7] Internet-Draft SIP Directed Transcoding February 2003 With C's and S's SDP, the transcoding application server T then invites the media server M with the SDP with the appropriate plumbing as specified in [I-D.camarillo-mmusic-source-sink]. The media server M responds with the appropriate media server sinks for S to C (MC) and C to S (MS) in message (6). The transcoding application server T sends the media server sink for S to C (7) and C acknowledges the connection (8). The transcoding application server acknowledges the connection to the media server M (9). Finally, the transcoding application server T sends the media server sink for C to S in the acknowledgement (10). At this point we have a transcoding stream (11). 3.2 Using Conference Bridge An alternative method of constructing a transcoding server from a transcoding application server and media server is to create a conference. o Take the transcoding Request URI and extract the target Request URI o Invite a classical media server to the dialog o Invite the target Request URI, using mechanisms described in sip-deaf [9] Here is a typical network topology. +--------+ INVITE sip:xcod=sip%3atarget%40example.com@ms.example.com | UAC or |-------\ +-------------+ | Proxy | \------------------->| Transcoding | +--------+ | App. Server | +-------------+ INVITE target@example.com / | INVITE +-----+ /--------------------/ | xcod@example.com | UAS |<-----/ V +-----+ RTP +--------------+ \==============================| Media Server | +--------------+ Following the example laid out in sip-deaf [9], here is a sample call flow. C T M S Burger Expires August 25, 2003 [Page 8] Internet-Draft SIP Directed Transcoding February 2003 | | | | | INVITE sip:xcod=sip%3atarget%40example.com@t.example.com |------------>| | | (1) | SDP C | | | | | | | | 100 Trying | | | |<------------| | | (2) | | | | | | INVITE sip:conf=id@ms.example.net | |-------------->| | (3) | | SDP C | | | | | | | | 200 OK | | | |<--------------| | (4) | | SDP MS | | | | | | | | INVITE target@example.com | | |----------------------------->| (5) | | no SDP | | | | | 200 OK | | |<-----------------------------| (6) | | | SDP S | | | | | | | INVITE sip:conf=id@ms.example.net | |-------------->| | (7) | | SDP S | | | | | | | | 200 OK | | | |<--------------| | (8) | | SDP MC | | | | | | | 200 OK | | | |<------------| | | (9) | SDP MS | | | | | | | | ACK | | | |------------>| ACK | | (10) | |-------------->| | (11) | | ACK | | | |----------------------------->| (12) | | SDP MC | | | | | | | | RTP | RTP | |<===========================>|<============>| (13) | | | | Here is a detailed description of the operation of the mechanism. Burger Expires August 25, 2003 [Page 9] Internet-Draft SIP Directed Transcoding February 2003 First, the UAC or Proxy C issues an INVITE to the transcoding application server T with C's SDP in message (1). The transcoding application server T responds with a 100 Trying (2), as it may take some time to coordinate the media server and UAS. The transcoding application server T then invites the media server M to a conference with the ID id with the SDP for C (3). The media server M responds with a 200 OK with what will be the transcoded version of S's SDP in message (4). Note the user of the conference SIP Request-URI as specified by netann [10]. The transcoding application server T then invites the UAS S with no SDP in message (5). The UAS S responds with its SDP in message (6). With the UAS' SDP, the transcoding application server invites the media server M to the same conference in (3) in message (7). The media server responds to the request with a 200 OK with what will be the transcoded version of C's SDP in message (8). The transcoding application server T sends the transcoded version of S' SDP in message (9). The UAC C acknowledges the request in message (10), which T relays to the media server M (11). The transcoding application server T then sends the transcoded version of C's SDP to the UAS S in message (12). At this point, we have the transcoded RTP stream (13). Burger Expires August 25, 2003 [Page 10] Internet-Draft SIP Directed Transcoding February 2003 4. Security Considerations Yes, there definitely will be a -01! Burger Expires August 25, 2003 [Page 11] Internet-Draft SIP Directed Transcoding February 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Camarillo, G. and E. Burger, "The source and sink attributes for the Session Description Protocol", draft-camarillo-mmusic-source-sink-00 (work in progress), September 2002. [3] 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. [4] ISO, "Codes for the representation of names of languages -- Part 1: Alpha-2 code", ISO 639-1, July 2002. [5] ISO, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO 3166-1, October 1997. [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [8] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993. Burger Expires August 25, 2003 [Page 12] Internet-Draft SIP Directed Transcoding February 2003 Informative References [9] Camarillo, G., "Transcoding Services Invocation in the Session Initiation Protocol", draft-camarillo-sip-deaf-01 (work in progress), November 2002. [10] Burger, E., Van Dyke, J., O'Connor, W. and A. Spitzer, "Basic Network Media Services with SIP", draft-burger-sipping-netann-04 (work in progress), January 2003. [11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [12] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002. [13] Burger, E., Van Dyke, J. and A. Spitzer, "SnowShore Media Server Control Markup Language and Protocol", draft-vandyke-mscml-00 (work in progress), November 2002. [14] World Wide Web Consortium, "Voice Extensible Markup Language (VoiceXML) Version 2.0", W3C Working Draft , April 2002, . [15] Callaghan, B., "NFS URL Scheme", RFC 2224, October 1997. [16] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC 3010, December 2000. [17] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [18] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001. Burger Expires August 25, 2003 [Page 13] Internet-Draft SIP Directed Transcoding February 2003 Author's Address Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA EMail: e.burger@ieee.org Burger Expires August 25, 2003 [Page 14] Internet-Draft SIP Directed Transcoding February 2003 Appendix A. Acknowledgements The transcoding design team includes Gonzalo Camarillo, Henning Schulzrinne, and Arnoud van Wijk. Burger Expires August 25, 2003 [Page 15] Internet-Draft SIP Directed Transcoding February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Burger Expires August 25, 2003 [Page 16] Internet-Draft SIP Directed Transcoding February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Burger Expires August 25, 2003 [Page 17]