One document matched: draft-garcia-mmusic-multiple-ptimes-problem-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 03:49:42 |