Multi-Transcoding Scenario March 2006 SIPPING Working Group Taegyu Kang Internet-Draft Doyoung Kim Category: Informational Haewon Jung Expires: September 5, 2006 ETRI March 6, 2006 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 September 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Taegyu Kang Expires - September 2006 [Page 1] Multi-Transcoding Scenario March 2006 Abstract This document presents miscellaneous transcoding error cases and multi-transcoding scenarios. The miscellaneous transcoding errors can occur where there is a codec mismatch between two parties during SIP/SDP codec negotiation in a multi-transcoding environment. The multi-transcoding scenarios are useful for network environments with a signaling/media path separation and multi-transcoding. Taegyu Kang Expires - September 2006 [Page 2] Multi-Transcoding Scenario March 2006 Table of Contents 1. Introduction...................................................4 2. Scope..........................................................5 3. Terminology....................................................5 4. Definitions....................................................5 5. Response code for Miscellaneous Transcoding Error Cases........5 5.1 Not Acceptable at T and B for calling part A...............6 5.2 Not Acceptable at T and A for called part B................7 6. Use Cases of Multi-transcoding.................................7 6.1 Use cases for heterogeneous networks.......................8 6.2 Use cases for ITSPs........................................8 6.3 Use cases for wideband codecs..............................9 7. Multi-transcoding Scenario.....................................9 7.1 Multi-transcoding Scenario 1..............................10 7.2 Multi-transcoding Scenario 2..............................10 7.3 Multi-transcoding Scenario 3..............................11 8. The Maximum Tn of Multi-transcoding...........................12 9. Security Considerations.......................................13 10. IANA Considerations..........................................13 11. References...................................................13 11.1 Normative References.....................................13 11.2 Informative References...................................14 Author's Addresses...............................................15 Intellectual Property Statement..................................15 Taegyu Kang Expires - September 2006 [Page 3] Multi-Transcoding Scenario March 2006 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. Codecs have adapted depending on networks, media types, and applications. We need to define transcoding error and scenario between different codecs for BcN(broadband convergence network). 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 without a common codec. A transcoding function is needed in cases of interworking between different networks with different codecs and communicating between different applications as well as cases 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 where there is a codec mismatch between two parties during SIP/SDP codec negotiation in a multi-transcoding environment. 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. Taegyu Kang Expires - September 2006 [Page 4] Multi-Transcoding Scenario March 2006 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 AAC Advanced Audio Coding 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 SBC Session Border Controllers SDP Session Description Protocol SIP Session Initiation Protocol ToIP Text over Internet Protocol VoIP Voice over Internet Protocol 5. Response code for Miscellaneous Transcoding Error Cases There are two paths at each node between calling party and called party[13-14]. One is signaling path. The other is media path. Client Taegyu Kang Expires - September 2006 [Page 5] Multi-Transcoding Scenario March 2006 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 to adjacent party by transcodec. Data at T for a codec negotiating MUST consist of supporting media at T'. The method for maintain consisting between T and T' is beyond the scope of this document. That can use H.248/MEGACO, MGCP, or an internal proprietary protocol. +-------+ +-------+ +-------+ | 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 488(Not Acceptable Here) after trying to connect B via T, A does not know which is 488(Not Acceptable Here), whether it occurred at T or B. We want to know which part(T or B) an error occurred. We need an additional response code to 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, etc. 5.1 Not Acceptable at T and B for calling part A If T and B can not support codec a, T SHOULD reply to A with a new response code xx1(Not Supportable at T) after receiving 488(Not Acceptable Here) from B. This new response code notifies the calling party with the more detailed reason than 406(Not Acceptable). This means not only 488(Not Acceptable Here) at called party B but also transcoding not supportable A at T. Taegyu Kang Expires - September 2006 [Page 6] Multi-Transcoding Scenario March 2006 +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | | a | | | a | | c-b | | b | +-------+ +-------+ +-------+ Figure 2: Not Acceptable at T and B for A If calling party receives the xx1(Not Supportable at T), the calling party can try to connect a calling party B through another T. 5.2 Not Acceptable at T and A for called part B If T can not support codec b, T SHOULD reply to A with response code xx2(Not Supportable at T) after receiving 488(Not Acceptable Here) from B. +-------+ +-------+ +-------+ | A |-----SIP---->| T |-----SIP---->| B | | | a | a-c | a | | | a | | a-d | Tc | b | +-------+ +-------+ Td +-------+ Figure 3: Not Acceptable at T and A for B If calling party receives the xx1(Not Supportable at T), the calling party will not try to connect a calling party B through T any more. 6. Use Cases of Multi-transcoding There are three kinds of use cases for multi-transcoding. - one or more heterogeneous networks - one or more ITSPs - one or more wideband speech codecs We can make a configuration as an example of multi-transcoding use cases in Figure 4. In this convention, Capital letters mean a node and lowercase(a, b, c, d, and e) means a codec. Taegyu Kang Expires - September 2006 [Page 7] Multi-Transcoding Scenario March 2006 PacketCable Wibro +-----+ +-----+ +-----+ +-----+ | F |-SIP--| T4 |-SIP-----+--SIP----| T5 |-SIP--| G | | | d | | | | | c | | | d | | c-d | | | d-c | | c | +--+--+ +-----+ | +--+--+ +-----+ | | | SIP | IP-PBX | ITSP | IMS +-----+ +-----+ +--+--+ +--+--+ +-----+ | A |-SIP--| T1 |-SIP--| T2 |-SIP--| T3 |-SIP--| D | | | a | a-e | | b-c | | a-d | d | | | a | | a-b | | b-d | | d-e | | d | +-----+ +--+--+ +--+--+ +--+--+ +-----+ | | | | SIP|c | | | | +-----+ | +--+--+ | +-----+ | B |-SIP-----+ | C | +----SIP--| E | | | b | | e | | | b | | c | | e | +-----+ +-----+ +-----+ Figure 4: An Example of Multi-transcoding use case 6.1 Use cases for heterogeneous networks There are one or more heterogeneous networks[15]: enterprise networks using IP-PBX, ITSP(Internet Telephony Service Provider), IMS in 3GPP2, PacketCable, and Wibro. They will not use a common codec. So, they need multi transcoding such as; - use case 1: A(a) - IP PBX T1(a-e, a-b) - ITSP T2(b-c, b-d) - IMS T3(a-d, d-e) - D(d) - use case 2: A(a) - IP PBX T1(a-e, a-b) - ITSP T2(b-c, b-d) - PacketCable T4(c-d) - F(d) - use case 3: E(e) - IMS T3(a-d, d-e) - Wibro T5(d-c) - G(c) 6.2 Use cases for ITSPs There are one or more ITSPs[16] or SBC(Session Border Controllers) because all of internet telephony subscribers will not subscribe to only one ITSP. There are a lot of domestic ITSPs and international ITSPs or ITXP. Internet telephony should be supported by any kind of terminal vendor even though it supports a specific codec. It also Taegyu Kang Expires - September 2006 [Page 8] Multi-Transcoding Scenario March 2006 supports multi call forwarding service. So, they need multi transcoding such as; - use case 4: C(c) - ITSP T2(c-b, b-d) - ITSP T6(b-a, b-d) - ITSP T7(a-d, d-e) - G(d) 6.3 Use cases for wideband codecs There are one or more wideband speech codecs. The wideband speech codecs for internet telephony are being developed: AMR-WB in 3GPP, VMR-WB in 3GPP2, G.729EV in ITU-T SG 16 Question 10, a wideband codec in ITU-T SG 16 Question 9, AAC(Advanced Audio Coding), and Speex[17,18]. A wideband codec encodes voice using 16,000 samples per second (50 ~ 7,000Hz), as opposed to the 8,000 samples per second (300 ~ 3,400Hz) by narrowband codec. The voice quality of wideband codec is better than one of narrowband codec due to supporting wider band. A tandem transcoding means to encode narrowband codec such as G.711. So, it makes down sampling and worsens the voice quality. If two parties (calling party and called party) have two different wideband codecs, transcoders should transcode a wideband codec to another wideband codec without tandem transcoding. If we use a common codec with G.711(tandem), there is no more need for multi-transcoding. But, we need multi-transcoding for supplying a wideband speech high quality to each side. - use case 5: wideband codec to wideband codec without tandem transcoding Multi-transcoding signaling can be useful for internet telephony environments supported by this standard. Multi-trascoder can cover the use case using one or more conference bridge transcoding models. 7. Multi-transcoding Scenario We explain scenarios in network environment with one more transcoding nodes. The transit party SHOULD provide all transcoding capability to the calling party and called party during call negotiation in 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 information whether it will be transcoded or not. The discriminator Taegyu Kang Expires - September 2006 [Page 9] Multi-Transcoding Scenario March 2006 prevents it from re-transcoding or transcoding-cycling in a multi- transcoding environment. Multi-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. 7.1 Multi-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 5: Multi-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. 7.2 Multi-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 - September 2006 [Page 10] Multi-Transcoding Scenario March 2006 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 decreases 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 6: Multi-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 have the bypass only capability at both of signaling path and media path in this scenario. 7.3 Multi-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 the codec sequence is a, Tc, Tb instead of Taegyu Kang Expires - September 2006 [Page 11] Multi-Transcoding Scenario March 2006 a, 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's a-b and T2's a-b or T2's a-c and T3's 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 7: Multi-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 have the bypass only capability at both signaling path and media path in this scenario. These scenarios effect Transcoding-cycling avoidance, minimizing of transcoding, call setup delay, and call waiting states during call set up. 8. The Maximum Tn of Multi-transcoding We have to define the maximum number Tn of multi-transcodings. The quality will be decreased according to increase in the number of transcodings. We SHOULD consider defining the maximum Tn to avoid 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 8: Maximum Tn over Case Taegyu Kang Expires - September 2006 [Page 12] Multi-Transcoding Scenario March 2006 The defining of maximum number Tn is for further study. This number will be smaller than Max-Forwards in SIP Extension for Instant Messaging[12]. 9. Security Considerations This document does not introduce any new security considerations. 10. IANA Considerations This document does not contain any IANA actions. 11. References 11.1 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- Taegyu Kang Expires - September 2006 [Page 13] Multi-Transcoding Scenario March 2006 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- 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. B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging," RFC 3428, December 2002 13. G. Klyne, "Protocol-independent Content Negotiation Framework," RFC 2703, September 1999 14. G. Klyne, "A Syntax for Describing Media Feature Sets," RFC 2533, March 1999 15. Chris Gallon, "Quality of service for next generation Voice over IP networks," MSF-TR-QoS-001.final," 2003 Feb 16. TIPHON, "Telecommunications and Internet Protocol Harmonization over Networks (TIPHON) Release 3; End-to-End Quality of Service in TIPHON Systems; Part 3: Signalling and Control of End-to-End Quality of Service (QoS)-V2.1.2," 2002. 11.2 Informative References 17. "Speexenc/speexdec, reference command-line encoder/decoder," Speex website http://www.speex.org/. 18. G. Herlein, S. Morlat, J. Jean-Marc, R. Hardiman, P. Kerr, "RTP Payload Format for the Speex Codec," draft-ietf-avt-rtp-speex- 00.txt, October 12, 2005 Taegyu Kang Expires - September 2006 [Page 14] Multi-Transcoding Scenario March 2006 Author's Addresses Taegyu Kang ETRI 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea EMail: tgkang@etri.re.kr Doyoung Kim ETRI 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea EMail: dyk@etri.re.kr Haewon Jung ETRI 161 Gajeong-Dong Yuseong-Gu, Deajon 305-350, Korea EMail: hw-jung@etri.re.kr 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. Taegyu Kang Expires - September 2006 [Page 15] Multi-Transcoding Scenario March 2006 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 (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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Taegyu Kang Expires - September 2006 [Page 16]