Network Working Group Peili. Xu Internet-Draft Huawei Technologies Expires: April 20, 2006 October 17, 2005 Codec specific parameters in SDP draft-xu-mmusic-sdp-codec-param-00 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 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract From time to time, there are discussions to describe some session parameters specific to the codecs in a media in the application of SDP [1]. Codec specific ptime and transport address are two examples. This document analyses those requirements, and provide a suggestion to extend SDP to solve the problem. Xu Expires April 20, 2006 [Page 1] Internet-Draft Codec specific parameters in SDP October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirement Analysis . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirement to support codec specific ptime . . . . . . . 5 3.2. Requirement to support codec specific transport address . 5 3.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Example of the SDP extension . . . . . . . . . . . . . . . . . 8 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Xu Expires April 20, 2006 [Page 2] Internet-Draft Codec specific parameters in SDP October 2005 1. Introduction SDP is defined for general real-time multimedia session description purposes and is extended for the negotiation of media encodings incorporated with other protocols like SIP [3]. As per RFC2327, a session description consists of a session-level description (details that apply to the whole session and all media streams) and optionally several media-level descriptions (details that apply onto to a single media stream). In general, session-level values are the default for all media unless overridden by an equivalent media-level value. In the media-level descriptions, each media description starts with an "m=" field, and is terminated by either the next "m=" field or by the end of the session description. A media field also has several sub-fields: m= The fourth and subsequent sub-fields are media formats. For audio and video, these will normally be a media payload type as defined in the RTP Audio/Video Profile. This list contains the payload formats that may be used in the session. In application, there may have different attributes for different media formats in one media stream. One example is the number of samples per packet (ptime) for RTP audio formats, media tools may support different packetization time for different audio formats. Another example is to provide different transport address and port for different media formats in some specific applications like transcoding gate way. The requirement to support codec specific parameters in SDP is analyzed here, examples of the possible extension is also given in this document. Part of the topic comes from the discussion on the mailing list. The purpose of this document is to act as a basis for discussion and hope to get the best solution from the community. Xu Expires April 20, 2006 [Page 3] Internet-Draft Codec specific parameters in SDP October 2005 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations. Xu Expires April 20, 2006 [Page 4] Internet-Draft Codec specific parameters in SDP October 2005 3. Requirement Analysis 3.1. Requirement to support codec specific ptime In voip, the number of samples per packet for RTP audio format is commonly called "ptime", the definition for it in RFC 2327 is like this: a=ptime: This gives the length of time in milliseconds represented by the media in a packet. This is probably only meaningful for audio data. It should not be necessary to know ptime to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetisation of audio. It is a media attribute, and is not dependent on charset. Although it should not be a key to decode RTP packet, any ptime should be accepted, in practice, many implementations don`t support such flexibility. If the received packet is not compatible to specified mode, the quality of voice will be bad. This always cause interworking problem in deployment. The requirement to support codec specific ptime may be summarized as follows: Req 1: Should support different ptime value for different codec formats in one media stream. Req 2: The content of codec specific ptime may be a list of supported values, e.g. 10 20 30. Req 3: The content of codec specific ptime may be contain scope of supported ptime values, e.g. 10-30. Req 4: If there is no codec specific ptime value, the media level ptime value shall be used. 3.2. Requirement to support codec specific transport address The transport address information for media stream contains two parts: connection address and port number. Connection address is defined like this: Xu Expires April 20, 2006 [Page 5] Internet-Draft Codec specific parameters in SDP October 2005 c=
It may be a session level description or media level description (in this case override the session level one for this media). Port number is one of the sub-fields in the definition of media stream information: m= From this we can see that we can not provide codec specific transport address information now. There may have requirements to support codec specific transport address information: 1) Direct transcoding function A direct transcoding model is introduced in [4]. +-------+ +-------+ +-------+ | |<----SIP---->| |<----SIP---->| | | A | | T | | B | | a |----Media----|a-b,a-c|----Media----| c | +-------+ +-------+ +-------+ Figure 1: Direct transcoding model In this model, when forwarding INVITE the transcoding function T can directly add his capability. The purpose is that if the called party B only support c, it will be connected to T, where as if it support a, it may still be connected to A directly. To fulfill this function, it`s required that T can provide transport address information for the codecs added by it, and with the other media information unchanged. For example, the SDP modified by T may be like this: Xu Expires April 20, 2006 [Page 6] Internet-Draft Codec specific parameters in SDP October 2005 v=0 o=A 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 A.anywhere.com t=0 0 m=audio 62986 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 // supported by A a=rtpmap:4 G723/8000 // Added by T [XXX T`s address information] // Added by T The requirement to support codec specific transport address information may be summarized as follows: Req 1: Should support different transport address information for different codec formats in one media stream. Req 2: The content of transport address information may contain connect address, port number or both. Req 3: If there are no codec specific transport address information, the session level or media level one shall be used. 3.3. Summary From the discussion above, we can see that there may have requirements for codec specific parameters. The parameter may contain ptime, transport address information or others. Xu Expires April 20, 2006 [Page 7] Internet-Draft Codec specific parameters in SDP October 2005 4. Example of the SDP extension Based on the discussion above, an example for the extension of SDP is illustrated here. 4.1. Format a=x-codecparam: This is a codec level attribute. Each codec may have several parameters each described in one line. The detail of each parameter should be defined separately. 1) ptime negotiation a=x-codecparam: ptime= e.g. a=x-codecparam:0 ptime=10, 20, 30 2) transport address negotiation a=X-codecparam: c=
a=X-codecparam: port= e.g. a=x-codecparam:0 c=IN IP4 127.0.0.1 a=x-codecparam:0 port=12345 Xu Expires April 20, 2006 [Page 8] Internet-Draft Codec specific parameters in SDP October 2005 5. Security Considerations There are no specific security issues here. Xu Expires April 20, 2006 [Page 9] Internet-Draft Codec specific parameters in SDP October 2005 6. IANA Considerations None. Xu Expires April 20, 2006 [Page 10] Internet-Draft Codec specific parameters in SDP October 2005 7. Acknowledgments Part of the information come from the discussion on ietf mailing list. Thanks for the suggestions and discussions from r.parthasarathi, christer.holmberg, Lyons,Terry and Colin Perkins. Xu Expires April 20, 2006 [Page 11] Internet-Draft Codec specific parameters in SDP October 2005 8. References 8.1. Normative References [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [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. 8.2. Informative References [4] Kang, T., Kim, D., and H. Jung, "The requirement for direct transcoding with Session Initiation Protocol", June 2005. Xu Expires April 20, 2006 [Page 12] Internet-Draft Codec specific parameters in SDP October 2005 Author's Address Peili Xu Huawei Technologies Bantian Shenzhen, Longgang 518129 China Phone: +86 755 28780808 Email: xupeili@huawei.com Xu Expires April 20, 2006 [Page 13] Internet-Draft Codec specific parameters in SDP October 2005 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Xu Expires April 20, 2006 [Page 14]