Direct Transcoding requirement June 2005 SIPPING Working Group Taegyu Kang Internet-Draft Doyoung Kim Expires: December 8, 2005 Haewon Jung ETRI June 9, 2005 The requirement for direct transcoding with Session Initiation Protocol 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 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 a "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 December 8, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document presents a set of Session Initiation Protocol (SIP) call control requirements that support communication with direct transcoding capability. Several solutions are addressed for transcoding service. Direct transcoding requires two kinds of requirements: the service requirement and call control requirement. Service requirement is no constraint of codec adaptation and interoperability of models. Call Taegyu Kang Expires - December 2005 [Page 1] Direct Transcoding requirement June 2005 control requirement is exchange of codec information and minimizing of call set up delay. The model might be applied to general-purpose services satisfying the requirements of multimedia applications without an additional INVITE. Taegyu Kang Expires - December 2005 [Page 2] Direct Transcoding requirement June 2005 Table of Contents 1. Introduction...................................................4 2. Purpose and scope..............................................4 3. Background.....................................................4 4. Service Requirement............................................7 4.1 No Constraint of Codec Adaptation..........................7 4.2 Interoperability of Models.................................7 5. Call Control Requirement.......................................8 5.1 Exchange of codec information..............................8 5.2 Minimizing of Call set up delay............................8 6. Security Considerations........................................9 7. IANA Considerations............................................9 References........................................................9 Author's Addresses...............................................10 Intellectual Property Statement..................................10 Taegyu Kang Expires - December 2005 [Page 3] Direct Transcoding requirement June 2005 1. Introduction Simple homogeneous terminals and special purpose terminals comprise the majority of existing network terminals. Communication media is getting more diverse in terms of the types of network terminals. However, the era of new communication media types through several kinds of network terminals such as hardware IP phones(POTS style, PDA style, mobile phone style), software IP phones(special purpose software phone, messenger phone, ITSP phone), POTS phones, ISDN phones and mobile phones is coming. We believe that transcoding services are a key solution to supporting these types of communication in heterogeneous networks and different capability terminals. We want to use a service network transparency even though it has wireline network, wireless network, internet, and broadcasting network with a horizontal structure. The IETF sipping WG has been developing two models for transcoding services: Third Party Call Control Transcoding Model[4][6-7] and Conference Bridge Transcoding Model[5]. The Third Party Call Control Transcoding Model is suitable for advanced end points that are able to perform third party call control. The Conference Bridge Transcoding Model is suitable for a centralized conference. These two models are useful for a specific application invoked rarely to support deaf, hard of hearing and speech-impaired individuals[2]. We need another model that is useful for general application[8] invoked frequently[9]. A transcoding function is needed in cases of interworking between different networks with different codecs and communicating between different applications (e.g., text and speech). 2. Purpose and scope The direct transcoding requirements described within this document. 3. Background There are heterogeneous networks, media types and applications. Some examples of heterogeneous networks are ones between PSTN and 3GPP/3GPP2, PSTN and Internet Telephony, or Internet Telephony and 3GPP/3GPP2. Examples of media types are a communication in real time between voice and text, video/voice and voice, or video/voice and text. Examples of applications are call forwarding and conference call. Codecs are adapted depending on networks, media types, and applications. We need a transcoding requirement between different codecs for global communication. Taegyu Kang Expires - December 2005 [Page 4] Direct Transcoding requirement June 2005 There are several cases for call scenarios with codecs 1) Case with same codec between calling party and called party +-------+ +-------+ | |<----SIP---->| | | A | | B | | a |----Media----| a | +-------+ +-------+ Figure 1: Case with same codec 2) Case with call setup failure due to codec mismatch +-------+ +-------+ | |<----SIP---->| | | A | | B | | a |----Media----| b | +-------+ +-------+ Figure 2: Case with call setup failure 3) Case with request for another transcoding server +-------+ +-------+ +-------+ | |<----SIP---->| |<----SIP---->| | | A | | B | | C | | a | | b |----Media----| a-b | +-------+ +-------+ +-------+ | | +-------Media-------------------------------+ Figure 3: Case for an additional request 4) Case with controlling by conference server +-------+ +-------+ +-------+ | |<----SIP---->| C |<----SIP---->| | | A | |a-b,a-c| | B | | a |----Media----| b-c |----Media----| b | +-------+ +---+---+ +-------+ | | +-------+ |<--------SIP---->| | | | D | +--------Media----| c | +-------+ Figure 4: Case with central controller Taegyu Kang Expires - December 2005 [Page 5] Direct Transcoding requirement June 2005 5) Case with transcoding processing in transit party +-------+ +-------+ +-------+ | |<----SIP---->| |<----SIP---->| | | A | | T | | B | | a |----Media----|a-b,a-c|----Media----| c | +-------+ +-------+ +-------+ Figure 5: Case with direct transcoding function Case 1 has the most efficient media processing among the 5 cases. Case 1 does not need transcoding because there is only one codec or the same codec. Case 2 can not connect a call due to codec mismatch. We should avoid Case 2 during call setup stage. Case 3 is a transcoding model by new INVITE to invoke transcoding in the third party. Case 4 is a transcoding model by re-INVITE to invoke transcoding in a transit party. Case 5 is a transcoding model by direct transcoding in a transit party. The Direct Transcoding Model, case 5, is a useful solution from the point of ITSP(Internet Telephony Service Provider). In an ITSP environment, all call control messages should be controlled by the ITSP server, ITSP can provide service to terminals with all kinds of codecs. ITSP media server has a transcoding function and call control by itself. This model has the advantage of no additional messages between nodes and no modification for SIP call set up standard. The Direct Transcoding Model can be one of the solutions to network convergence of PSTN, mobile network, internet telephony, and digital broadcasting TV. The models are compared by signaling traffic overhead. The Conference bridge model and the Third party transcoding server model need an additional signaling procedure for transcoding service whenever they are invoked. The additional signaling procedure includes an additional INVITE procedure with SIP/SDP between invoking point and serving point. Conference bridge model and Third party transcoding server model are useful for environments that rarely occur for the transcoding service. Taegyu Kang Expires - December 2005 [Page 6] Direct Transcoding requirement June 2005 4. Service Requirement The user requirements in this section are provided for the benefit of end user and the convergence network providers. 4.1 No Constraint of Codec Adaptation We should not restrict the use or choice of a specific codec. There are several adaptable codecs by network, end user, and ITSP. - The right of choice for codec by network - The right of choice for codec by end user - The right of choice for codec by ITSP Networks have adapted a specific codec since the PSTN era; G.711 in PSTN, AMR in GSM(3GPP), EVRC, QCELP or SMV in 3GPP. End users have adopted any codec since internet phone; G.723.1, G.729, G.711, and internet Low Bit Rate Codec (iLBC) Speech. ITSP tries to provide a transcoding function for wider service coverage. It is possible to communicate between users with a heterogeneous codec. We should make a model for more successful call set up regardless of different codecs between calling and called party. So, we can freely choose codecs according to our preference. Direct transcoding model should accept all kinds of codecs supported by network, end user, or ITSP. 4.2 Interoperability of Models We can make a call flow with a sequence of transcoding models according to a service requirement. The service requirements can be provided by a third party server, a central controlling server, or an intermediary provider. The available models are: - No transcoding model - 3pcc transcoding model - Conference call transcoding model - Direct transcoding model The direct transcoding model should not affect the other transcoding models; no transcoding model, 3pcc transcoding model, and conference call transcoding model. Even though the models are different between calling party and called party, direct transcoding model can communicate to the other side supported by a different model without any other requirements. Taegyu Kang Expires - December 2005 [Page 7] Direct Transcoding requirement June 2005 5. Call Control Requirement The following is a detailed description of the transcoding call control requirement. 5.1 Exchange of codec information Direct transcoding model should provide the below information to the other side. - a transcoding capability - a discriminator for codec characteristics - a preference order for codecs The transit party should provide all transcoding capability to calling party and called party during call set up procedures. This minimizes codec mismatch call setup failure due to a lack of codec negotiation information. A discriminator for codec characteristics should provide the codec information whether transcoded or not. The discriminator prevents re- transcoding or transcoding-cycling from occurring. The transcoding can decrease the quality of codec, so the number of transcodings are minimized if possible. A preference order for codecs should be provided by the other side according to a codec quality. The preference is useful for codec negotiation during the call set up. 5.2 Minimizing of Call set up delay End user requires connectivity, speed, and efficiency for internet telephony. The requirements of call set up are: - based on SIP and Offer/Answer - no interaction with user - minimize call set up delay due to transcoding - minimize the number of call waiting states during call set up procedure Direct transcoding model should be applied the principle based on SIP[1] and Offer/Answer[3]. The independence between the model and SIP is useful for its self-development and re-use independently. We need a model for various codecs without user interaction. Taegyu Kang Expires - December 2005 [Page 8] Direct Transcoding requirement June 2005 Transcoding processing time should be minimized during the setup. If we have to wait for a long time to setup another party, the transcoding model will be useless. The increase of call waiting states number for transcoding call set up procedure make the network performance worse. 6. Security Considerations This document does not introduce any new security considerations. 7. IANA Considerations This document does not contain any IANA actions. References 1. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session initiation protocol," RFC 3261, Internet Engineering Task Force, June 2002. 2. N. Charlton, M. Gasson, G. Gybels, M. Spanner, 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, Internet Engineering Task Force, Aug. 2002. 3. J. Rosenberg and H. Schulzrinne, " An offer/answer model with session description protocol (SDP)," RFC 3264, Internet Engineering Task Force, June 2002. 4. J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, " Best current practices for third party call control in the session initiation protocol," RFC 3725, Internet Engineering Task Force, Jan. 2004. Work in progress. 5. G. Camarillo, " The session initiation protocol conference bridge transcoding model," Internet Draft draft-camarillo-sipping- transc-b2bua-00, Internet Engineering Task Force, Aug. 2003. Work in progress. 6. G. Camarillo, " Framework for Transcoding with the Session Initiation Protocol," Internet Draft draft-ietf-transc-framework- 00.txt, Internet Engineering Task Force, Feb. 2004. Work in progress. 7. G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk, " Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)," Sep 2004 Work in progress. 8. A. van Wijk, " Framework of requirements for real-time text conversation using SIP," Internet Draft draft-vanwijk-sipping- Taegyu Kang Expires - December 2005 [Page 9] Direct Transcoding requirement June 2005 toip-00, Internet Engineering Task Force, Jan. 2004. Work in progress 9. Taegyu Kang, D.kim, Y. Kim, " Intelligent Transcoding Gateway Model for Transcoding with the Session Initiation Protocol," Internet Draft draft-taegyukang-sipping-transc-itg-00.txt, Internet Engineering Task Force, Jan. 2004. Work in progress Author's Addresses Taegyu Kang tgkang@etri.re.kr Multimedia Communications Team 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea Doyoung Kim dyk@etri.re.kr Multimedia Communications Team 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea Haewon Jung hw-jung@etri.re.kr BcN Core Technology Group 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea 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. Taegyu Kang Expires - December 2005 [Page 10] Direct Transcoding requirement June 2005 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Taegyu Kang Expires - December 2005 [Page 11]