Multi-Transcoding Scenario October 2005 SIPPING Working Group Taegyu Kang Internet-Draft Doyoung Kim Category: Informational Haewon Jung Expires: April 16, 2006 ETRI October 17, 2005 The Miscellaneous Transcoding Error Case and the Multi-Transcoding Scenario 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/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 April 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Taegyu Kang Expires - April 2006 [Page 1] Multi-Transcoding Scenario October 2005 This document presents miscellaneous transcoding error cases and multi-transcoding scenarios. The miscellaneous transcoding errors can occur when there is no common codec between two parties during SIP/SDP codec negotiation and when there is inconsistent data between signaling path and media path after SIP/SDP codec negotiation. The multi-transcoding scenarios are useful for network environments with a signaling/media path separation and multi-transcoding. Taegyu Kang Expires - April 2006 [Page 2] Multi-Transcoding Scenario October 2005 Table of Contents 1. Introduction...................................................4 2. Scope..........................................................5 3. Terminology....................................................5 4. Definitions....................................................5 5. Transcoding Error Cases........................................6 5.1 Not Acceptable at T and B: Nothing for A...................7 5.2 Not Acceptable at T and B: Nothing for B...................7 5.3 Inconsistency calling side.................................7 5.4 Inconsistency called side..................................8 6. Transcoding Scenario...........................................9 6.1 Transcoding Scenario 1.....................................9 6.2 Transcoding Scenario 2.....................................9 6.3 Transcoding Scenario 3....................................10 7. The Maximum Tn of transcoding.................................11 8. Security Considerations.......................................12 9. IANA Considerations...........................................12 Normative References.............................................12 Author's Addresses...............................................13 Intellectual Property Statement..................................13 Taegyu Kang Expires - April 2006 [Page 3] Multi-Transcoding Scenario October 2005 1. Introduction Communication media is getting more diverse in terms of the types of network terminals. Therefore, the era of new communication media types through several kinds of network terminals such as hardware IP phones and software IP phones, POTS phones, ISDN phones and mobile phones has been coming. We believe that transcoding services are a key solution to supporting uncommon communication media in heterogeneous networks and different capability terminals. Some examples of heterogeneous networks are ones between PSTN and 3GPP/3GPP2, PSTN and Internet Telephony, or Internet Telephony and 3GPP/3GPP2. Uncommon communication media can occur with communication between voice and text, video/voice and voice, or video/voice and text. Codec has adapted depending on networks, media types, and applications. We need to define transcoding error and scenario between different codecs for BcN(broadband convergence network). The speech codecs have been used in different networks according to the network characteristics; G.711 in PSTN, AMR in GSM/3GPP, EVRC, QCELP or SMV in 3GPP2. End users have adopted any codec since internet phone; G.723.1, G.729, G.711, and internet Low Bit Rate Codec (iLBC). ITSP(Internet Telephony Service Provider) tries to provide a transcoding function for a wider service coverage. Thus, it is possible to communicate between users with an uncommon codec. A transcoding function is needed in cases of interworking between different networks with different codecs and communicating between different applications as well as case in support of deaf, hard of hearing and speech-impaired individuals The IETF sipping WG has been developing three models with SIP[1] for transcoding services: ToIP(Text over IP), Third Party Call Control Transcoding Model, and Conference Bridge Transcoding Model[3-8]. Transcoding SHOULD apply by the principle based on SIP and SDP Offer/Answer[2]. This document presents miscellaneous transcoding error cases and the multi-transcoding scenarios. The miscellaneous transcoding error can occur when there is no common codec between two parties during SIP/SDP codec negotiation and when there is inconsistent data between signaling path and media path after SIP/SDP codec negotiation. The inconsistency cases are caused by transcodec error itself, wrong codec information delivery, protocol error between MG and MGC, MG/MGC internal error, and unexpected exception error. Taegyu Kang Expires - April 2006 [Page 4] Multi-Transcoding Scenario October 2005 The error cases and scenarios in this document are helpful for more specifically defining error cause and/or a solution of ITSP interworking. Scenarios are useful for network environment of signaling/media path separation and multi-transcoding. 2. Scope This document is focused on error cases and scenarios for multi- transcoding. The cases and scenarios can be used in network environments: broadband convergence networks with SIP based internet, 2G, 2.5G, 3G, CDMA, ISDN, and PSTN. This document excludes SIP/SDP Codec OFFER/ANSWER, Codec format Error, bit stream inconsistency between both sides, and connectivity error. 3. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [11] and indicate requirement levels for compliant implementations. 4. Definitions 2G Second generation cellular (mobile) 2.5G Enhanced second generation cellular (mobile) 3G Third generation cellular (mobile) 3PCC Third Party Call Control BcN Broadband convergence Network CDMA Code Division Multiple Access GSM Global System of Mobile Communication ISDN Integrated Services Digital Network ITSP Internet Telephony Service Provider ITU-T International Telecommunications Union-Telecommunications Standardization Sector PSTN Public Switched Telephone Network RTP Real Time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol ToIP Text over Internet Protocol VoIP Voice over Internet Protocol Taegyu Kang Expires - April 2006 [Page 5] Multi-Transcoding Scenario October 2005 5. Transcoding Error Cases The transit party SHOULD provide all transcoding capability to the calling party and called party during call negotiation in call set up procedures[12-13]. This minimizes codec mismatch call setup failure due to a lack of codec negotiation information. A discriminator for codec characteristics SHOULD provide the information whether it will be transcoded or not. The discriminator prevents it from re-transcoding or transcoding-cycling occurring. Transcoding can decrease the quality of the codec, so we SHOULD try to minimize the number of transcodings if it is possible. A preference order among candidate codecs SHOULD send to the other side according to the quality of codec. The preference is useful for codec negotiation during the call set up. There are two paths at each node between calling party and called party[15-16]. One is signaling path. The other is media path. Client side has both of them in one physical entity, even though it has two paths logically. Intermediary node T has two separate paths logically and physically. The signaling path will be located at T. The media path will be located at T'. T negotiates supportable media to adjacent party by SIP/SDP. T' supports media adjacent party by transcodec. Data at T for negotiating MUST consist of supporting media at T'. The method for consisting data between T and T' is beyond the scope of this document. That can use H.248/MEGACO, MGCP, or internal proprietary one. +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | a-b | a | | | a | | c-d | Tb | b | +---+---+ +---+---+ +---+---+ | | | | | | | | | +---+---+ +---+---+ +---+---+ | A' |----Media----| T' |----Media----| B' | | | a' | | b' | | | a' | | a'-b' | | b' | +-------+ +-------+ +-------+ Figure 1: Normal Transcoding Case We are focused on ERROR Cases for transcoding service. If A receives Not Acceptable Here: 488 after trying to B via T, A does not know which is Not Acceptable Here, whether it occurred at T or B. The Taegyu Kang Expires - April 2006 [Page 6] Multi-Transcoding Scenario October 2005 cases are helpful to know at which part an error occurred. The error is different from 404: Not Found, 406: Not Acceptable, 415: Unsupported Media Type, 500 Internal Server Error, 503 Service Unavailable, and 606: Not Acceptable[1]. These are derived from several steps during call setup sequences; destination finding step, media type check step, codec negotiation step, media format and decoding step, and etc. 5.1 Not Acceptable at T and B: Nothing for A If T and B can not support a codec, T SHOULD reply to A with Not Acceptable:406 and Not transcoding supportable A at T after receiving Not Acceptable Here: 488 from B. +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | | a | | | a | | c-b | | b | +-------+ +-------+ +-------+ Figure 2: Not Acceptable at T and B: Nothing for A 5.2 Not Acceptable at T and B: Nothing for B If T and B can not support a codec, T SHOULD reply to A with Not Acceptable and transcoding supportable A at T after receiving Not Acceptable Here: 488 from B. +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | a-c | a | | | a | | a-d | Tc | b | +-------+ +-------+ Td +-------+ Figure 3: Not Acceptable at T and B: Nothing for B 5.3 Inconsistency calling side After SIP media negotiation has finished successfully, this inconsistency error case can occur during media communication between calling sides. It is caused by inconsistency between T and T'. This scenario does not mean RTP payload format error for a specific codec and malfunction of T'. Taegyu Kang Expires - April 2006 [Page 7] Multi-Transcoding Scenario October 2005 +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | a-b | a | | | a | | c-d | Tb | b | +---+---+ +---+---+ +---+---+ | | | | | | | | | +---+---+ +---+---+ +---+---+ | A' |----Media----| T' |----Media----| B' | | | a' | | b' | | | a' | | c'-b' | | b' | +-------+ +-------+ +-------+ Figure 4: Inconsistency calling side Error Case T MUST reply to calling party A with Internal Server Error: 500 or Service Unavailable: 503. We need to define a new Error Code for this case instead of 500 and 503. 5.4 Inconsistency called side After SIP call sets up successfully, an error can occur during media communication between called sides. It is caused by inconsistency between T and T'. This scenario does not mean RTP payload format error for a specific codec and malfunction of T'. +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | a-b | a | | | a | | c-d | Tb | b | +---+---+ +---+---+ +---+---+ | | | | | | | | | +---+---+ +---+---+ +---+---+ | A' |----Media----| T' |----Media----| B' | | | a' | | b' | | | a' | | a'-c' | | b' | +-------+ +-------+ +-------+ Figure 5: Inconsistency called side Error Case Taegyu Kang Expires - April 2006 [Page 8] Multi-Transcoding Scenario October 2005 T MUST reply to called party B with Internal Server Error: 500 or Service Unavailable: 503. We need to define a new Error Code for this case instead of 500 and 503. 6. Transcoding Scenario We explain scenarios in network environment with one more transcoding nodes. 6.1 Transcoding Scenario 1 The T (Transcoding intermediary node) can send to called side party with its transcoding capabilities based on received calling side party media. T1 sends to T2 the codec a from A and the Tb from T1. T2 sends to T3 the a from A, the Tb from T1, and the Tc from T2. T3 sends to B the a from A, the Tb from T1, the Tc from T2, and the Td from T3. +-----+ +-----+ +-----+ +-----+ +-----+ | A |-SIP->| T1 |-SIP->| T2 |-SIP->| T3 |-SIP->| B | | | a | | a | | a | | a | | | a | | a-b | Tb | b-c | Tb | c-d | Tb | d | +--+--+ +--+--+ +--+--+ Tc +--+--+ Tc +--+--+ | | | | Td | | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | A |-SIP->| T1' |-SIP->| T2' |-SIP->| T3' |-SIP->| B | | | a | | b | | c | | d | | | a | | a-b | | b-c | | c-d | | d | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 6: Transcoding Scenario 1 T1 has the codec negotiation a between A and T1, Tb between T1 and T2, Tc between T2 and T3, and Td between T3 and B. There are three kinds of transcoding at both the signaling path and the media path in this scenario. 6.2 Transcoding Scenario 2 The T (Transcoding intermediary node) can send to called side party with its transcoding capabilities based on received calling side party media. Taegyu Kang Expires - April 2006 [Page 9] Multi-Transcoding Scenario October 2005 T1 sends to T2 the a from A and the Tb from T1. T2 sends to T3 the a from A, the Tb from T1, and the Tc from T2. T3 sends to B the a from A, the Tb from T1, the Td from T3, and the Tc from T2. T3 has the capability which transcode directly higher priority codec a to another codec Td, so codec sequence is a, Tb, Td, Tc instead of a, Tb, Tc, Td. This method is useful for minimizing the number of transcodings. We assume that transcoder decrease the original media quality. +-----+ +-----+ +-----+ +-----+ +-----+ | A |-SIP->| T1 |-SIP->| T2 |-SIP->| T3 |-SIP->| B | | | a | | a | | a | | a | | | a | | a-b | Tb | b-c | Tb | a-d | Tb | d | +--+--+ +--+--+ +--+--+ Tc +--+--+ Td +--+--+ | | | | Tc | | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | A |-SIP->| T1' |-SIP->| T2' |-SIP->| T3' |-SIP->| B | | | a | | a | | a | | d | | | a | | | | | | a-d | | d | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 7: Transcoding Scenario 2 T3 has the codec negotiation a between A and T3, and Td between T3 and B, so A to T3 media path is a and T3 to B media path is d. T1 and T2 has the bypass only capability at both of signaling path and media path in this scenario. 6.3 Transcoding Scenario 3 The T (Transcoding intermediary node) can send to called side party with its transcoding capabilities based on received calling side party media. T1 sends to T2 the a from A and the Tb from T1. T2 sends to T3 the a from A, the Tb from T1/T2, Tc from T2. T3 sends to B the a from A, the Tb from T1/T2, and the Tc from T2/T3. There are two kinds of priority decision methods. One is based on first order; first order is first priority. The other is based on quality; If T3 has two alternatives (one is a pair of wideband codec a and narrowband codec Tb, the other is a pair of wideband codec a and wideband codec Tc), so codec sequence is a, Tc, Tb instead of a, Taegyu Kang Expires - April 2006 [Page 10] Multi-Transcoding Scenario October 2005 Tb, Tc. We can make quality the first priority and order sequence second. We assume that wideband codec has better quality than narrowband. We do not consider the performance of transcoder: T1' a-b and T2' a-b or T2' a-c and T3' a-c. +-----+ +-----+ +-----+ +-----+ +-----+ | A |-SIP->| T1 |-SIP->| T2 |-SIP->| T3 |-SIP->| B | | | a | | a | a-b | a | | a | | | a | | a-b | Tb | a-c | Tc | a-c | Tc | c | +--+--+ +--+--+ +--+--+ Tb +--+--+ Tb +--+--+ | | | | | | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ | A |-SIP->| T1' |-SIP->| T2' |-SIP->| T3' |-SIP->| B | | | a | | a | | c | | c | | | a | | | | a-c | | | | c | +-----+ +-----+ +-----+ +-----+ +-----+ Figure 8: Transcoding Scenario 3 T3 has the codec negotiation a between A and T3, and Tc between T3 and B, so A to T3 media path is a and T3 to B media path is c. T1 and T2 has the bypass only capability at both of signaling path and media path in this scenario. These scenarios effect Transcoding-cycling avoidance, minimizing of transcoding, call setup delay, call waiting states during call set up. 7. The Maximum Tn of transcoding We have to define the maximum number of Tn. The quality will be decreased according to increase in the number of transcodings. We SHOULD consider defining the maximum Tn for the protection of quality deterioration and complex interoperability. +-----+ +-----+ +-----+ +-----+ +-----+ | A |-SIP->| T1 |-SIP->| T2 |-SIP->| Tn |-SIP->| B | | | a | | a | | a | | a | | | a | | a-b | Tb | b-c | Tb | c-d | Tb | d | +-----+ +-----+ +-----+ Tc +-----+ Tc +-----+ Td Figure 9: Maximum Tn over Case Taegyu Kang Expires - April 2006 [Page 11] Multi-Transcoding Scenario October 2005 The defining of maximum number Tn is for further study. This number will be smaller than Max-Forwards in SIP Extension for Instant Messaging[14]. 8. Security Considerations This document does not introduce any new security considerations. 9. IANA Considerations This document does not contain any IANA actions. Normative 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. J. Rosenberg and H. Schulzrinne, " An offer/answer model with session description protocol (SDP)," RFC 3264, Internet Engineering Task Force, June 2002. 3. 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. 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. 5 G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk, "transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)," RFC4117, Internet Engineering Task Force, June 2005. 6. G. Camarillo, " The session initiation protocol conference bridge transcoding model," Internet Draft draft-ietf-sipping-transc- conf-00, Internet Engineering Task Force, June 2005. Work in progress. 7. G. Camarillo, " Framework for Transcoding with the Session Initiation Protocol," Internet Draft draft-ietf-sipping-transc- framework-02.txt, Internet Engineering Task Force, June 2005. 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 - April 2006 [Page 12] Multi-Transcoding Scenario October 2005 toip-03, Internet Engineering Task Force, Sept. 2005. 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 10. Taegyu Kang, D.kim, H. Jung, " The requirement for direct transcoding with Session Initiation Protocol," Internet Draft draft-kang-sipping-dtransc-requirement-00.txt, Internet Engineering Task Force, June. 2005. Work in progress 11. S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, IETF, March 1997 12. J. Rosenberg, H. Schulzrinne, "P. Kyzivat, Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)," RFC 3840, August 2004 13. J. Rosenberg, H. Schulzrinne, P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)," RFC 3841, August 2004 14. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging," RFC 3428, December 2002 15. G. Klyne, "Protocol-independent Content Negotiation Framework," RFC 2703, September 1999 16. G. Klyne, "A Syntax for Describing Media Feature Sets," RFC 2533, March 1999 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 Taegyu Kang Expires - April 2006 [Page 13] Multi-Transcoding Scenario October 2005 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. 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 (2005). 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 Taegyu Kang Expires - April 2006 [Page 14] Multi-Transcoding Scenario October 2005 Funding for the RFC Editor function is currently provided by the Internet Society. Taegyu Kang Expires - April 2006 [Page 15]