MMUSIC Working Group M. Garcia-Martin Internet-Draft M. Willekens Intended status: Informational Nokia Siemens Networks Expires: November 30, 2007 P. Xu Huawei Technologies May 29, 2007 Multiple Packetization Times in the Session Description Protocol (SDP): Problem Statement draft-garcia-mmusic-multiple-ptimes-problem-00.txt 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 November 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides a problem statement with respect to the presence of a single packetization time (ptime) attribute in SDP media descriptions that contain several unrelated codecs. Garcia-Martin, et al. Expires November 30, 2007 [Page 1] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 3. Conclusion and next steps . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Garcia-Martin, et al. Expires November 30, 2007 [Page 2] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 1. Introduction The Session Description Protocol (SDP) [RFC4566] provides a protocol for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A session description in SDP includes the session name and purpose, the media comprising the session, information needed to receive the media (addresses, ports, formats, etc.), and some other information. In the SDP media description part, the m-line contains the media type (e.g. audio), a transport port, a transport protocol (e.g. RTP/AVP) and a media format description which depends on the transport protocol. For the transport protocol RTP/AVP or RTP/SAVP, the media format sub- field can contain a list of RTP payload type numbers. See RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], Table 4. For example: "m=audio 49232 RTP/AVP 3 15 18" indicates the audio encoders GSM, G.728 and G.729. Further, the media description part can contain additional attribute lines that complement or modify the media description line. Of interest for this memo are the 'ptime' and 'maxptime' attributes. According to RFC 4566 [RFC4566], the 'ptime' attribute gives the length of time in milliseconds represented by the media in a packet, and the 'maxptime' gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. These attributes modify the whole media description line, which can contain an extensive list of payload types. In other words, these attributes are not specific to a given codec. RFC 4566 [RFC4566] also indicates that it should not be necessary to know ptime to decode RTP or vat audio since the 'ptime' attribute is intended as a recommendation for the encoding/packetisation of audio. However, once more, the existing 'ptime' attribute defines the desired packetization time for all the payload types defined in the corresponding media description line. End-devices can be configured with different codecs and for each codec a different packetization time can be indicated. However, there is no clear way to exchange this type of information between different user agents and this can result in lower voice quality, network problems or performance problems in the end-devices. Garcia-Martin, et al. Expires November 30, 2007 [Page 3] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 2. Problem Statement The packetization time is an important parameter which helps in reducing the packet overhead. Many voice codecs use a certain frame length to determine the coded voice filter parameters and try to find a certain optimum between the perceived voice quality (measured by the Mean Option Score (MOS) factor), and the required bitrate. When a packet oriented network is used for the transfer, the packet header induces an additional overhead. As such, it makes sense to try to combine different voice frame data in one packet (up to a Maximum Transmission Unit (MTU)) to find a good balance between the required network resources, end-device resources and the perceived voice quality influenced by packet loss, packet delay, jitter. When the packet size decreases, the bandwidth efficiency is reduced. When the packet size increases, the packetization delay can have a negative impact on the perceived voice quality. The RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551], Table 1, indicates the frame size and default packetization time for different codecs. The G.728 codec has a frame size of 2,5 msec/frame and a default packetization time of 20 msec/ packet. For G.729 codec, the frame size is 10 msec/frame and a default packetization time of 20 msec/packet. When more and more telephony traffic is carried over IP-networks, the quality as perceived by the end-user should be no worse as the classical telephony services. For VoIP service providers, it is very important that endpoints receive audio with the best possible codec and packetization time. In particular, the packetization time depends on the selected codec for the audio communication and other factors, such as the Maximum Transmission Unit (MTU) of the network and the type of access network technology. As such, the packetization time is clearly a function of the codec and the network access technology. During the establishment of a new session or a modification of an existing session, an endpoint should be able to express its preference with respect to the packetization time for each codec. This would mean that the creator of the SDP prefers the remote endpoint to use certain packetization time when sending media with that codec. RFC 4566 [RFC4566] provides the means for expressing a packetization time that affects all the payload types declared in the media description line. So, there are no means to indicate the desired packetization time on a per payload type basis. Implementations have been using proprietary mechanisms for indicating the packetization time per payload type, leading to lack of interoperability in this area. One of these mechanisms is the 'maxmptime' attribute, defined Garcia-Martin, et al. Expires November 30, 2007 [Page 4] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 in the ITU-T Recommendation V.152 [ITU.V152], which "indicates the supported packetization period for all codec payload types". Another one is the 'mptime' attribute, defined in the PacketCable Network- Based Call Signaling Protocol Specification [PKT.PKT-SP-EC-MGCP], which indicates "a list of packetization period values the endpoint is capable of using (sending and receiving) for this connection". While all have similar semantics, there is obviously no interoperability between them, creating a nightmare for the implementor who happens to be defining a common SDP stack for different applications. A few RTP payload format descriptions, such as RFC 3267 [RFC3267], RFC 3016 [RFC3016], and RFC 3952 [RFC3952] indicate that the packetization time for such payload should be indicated in the 'ptime' attribute in SDP. However, since the 'ptime' attribute affects all the payload formats included in the media description line, it would not be possible to create a media description line that contains all the mentioned payload formats and different packetization times. The solutions range from considering a single packetization time for all the payload types, or creating a media description line that contains a single payload type. The issue of a given packetization for a specific codec has been captured in past RFCs. For example, RFC 4504 [RFC4504] contains a set of requirements for SIP telephony devices. Section 3.8 in that RFC also provides background information for the need of packetization time, which could be set by either the user or the administrator of the device, on a per codec basis. However, once more, if several payload formats are offered in the same media description line in SDP, there is no way to indicate different packetizations per payload format.. 3. Conclusion and next steps This memo advocates for the need of a standard mechanism to indicate the packetization time on a per codec basis, allowing the creator of SDP to include several payload formats in the same media description line with different packetization times. This memo encourage discussion in the MMUSIC WG mailing list in the IETF. The ultimate goal is to define a standard mechanism that fulfils the requirements highlighted in this memo. 4. Security Considerations This memo discusses a problem statement and requirements. As such, Garcia-Martin, et al. Expires November 30, 2007 [Page 5] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 no protocol that can suffer attacks is defined. 5. IANA Considerations This document does not request IANA to take any action. 6. References 6.1. Normative References [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 6.2. Informative References [ITU.V152] ITU-T, "Procedures for supporting voice-band data over IP networks.", ITU-T Recommendation V.152, January 2005. [PKT.PKT-SP-EC-MGCP] PacketCable, "PacketCable Network-Based Call Signaling Protocol Speciication", PacketCable PKT-SP-EC-MGCP-I11- 050812, August 2005. [RFC3016] Kikuchi, Y., Nomura, T., Fukunaga, S., Matsui, Y., and H. Kimata, "RTP Payload Format for MPEG-4 Audio/Visual Streams", RFC 3016, November 2000. [RFC3267] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003. [RFC3952] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech", RFC 3952, December 2004. [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony Device Requirements and Configuration", RFC 4504, May 2006. Garcia-Martin, et al. Expires November 30, 2007 [Page 6] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 Authors' Addresses Miguel A. Garcia-Martin Nokia Siemens Networks P.O.Box 6 Nokia Siemens Networks, FIN 02022 Finland Email: miguel.garcia@nsn.com Marc Willekens Nokia Siemens Networks Belgium Email: marc.willekens@nsn.com Peili Xu Huawei Technologies Bantian Longgang, Shenzhen 518129 China Email: xupeili@huawei.com Garcia-Martin, et al. Expires November 30, 2007 [Page 7] Internet-Draft Multiple ptimes in SDP: problem statement May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Garcia-Martin, et al. Expires November 30, 2007 [Page 8]