Internet Engineering Task Force Rajesh Kumar
Internet Draft Cisco Systems
Document: <draft-rajeshkumar-mmusic-gfmtp-00.txt> March 26, 2002
Category: Informational
Expires: September 26, 2002
Generic Format-Specific Parameter
Status of this Document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026
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.
1. Abstract
An SDP attribute, 'gfmtp', is defined to convey generic parameters that can
qualify a format, but are not and integral part of the definition (such as MIME)
for that format. Typically, these parameters can be applied to several different
formats. Examples are the boolean parameters 'vbd' (voiceband data) and 'ecan'
(echo cancellation). Values of the 'gfmtp' attribute must be registered with the
IANA. This document may be folded into another document such as the new SDP
specification.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119.
3. Introduction
There is a need within SDP to qualify formats, such as those of a codec, with
additional parameters not included in their definition. The 'fmtp' parameter [3]
Kumar Informational 1
Generic Format-Specific Parameter March 2002
may be used for only those parameters included in the format definition or
template e.g. MIME.
For example, there is a need to distinguish between a payload type associated
with voice and a payload type associated with voiceband data. The rationale is
twofold:
* At the receiver, voiceband data traffic is found to work best with fixed-size
jitter buffers, while adaptive jitter buffers are optimal for voice.
* Packet loss concealment algorithms are the receiver are suitable for voice,
but not for voiceband data.
As another example, there is a need to associate echo cancellation with
different media formats.
This issue was discussed in a MMUSIC session of the 53rd IETF during the
discussion of [1], which is obsoleted by this internet draft. This internet
draft is an attempt to capture the consensus of MMUSIC in this area.
4. Proposed representation in SDP
The SDP attribute, gfmtp, is defined as:
a=gfmtp:<format><parameter list>
<parameter list> is represented as a semicolon-separated list of
"parameter=value" pairs. The format may be an RTP payload type.
Like all other SDP attributes, this SDP attribute is optional. Parsers that do
not recognize it should be able to ignore it. The only adverse effect is that
the other end may not apply the special treatments associated with the codec.
For parameters like 'vbd' and 'ecan', this might result in some degradation.
Current parameter definitions are the boolean (yes/no) parameters 'vbd'
(voiceband data) and 'ecan' (echo cancellation). Other possible parameters are
numeric gain control values.
An example media description in SDP might be:
m=audio 3456 RTP/AVP 0 15 98 99
a=rtpmap:98 PCMU/8000
a=gfmtp:98 vbd=on;ecan=off
a=rtpmap:99 G726-32/8000
a=fmtp:99 vbd=on;ecan=on
This specifies dynamic RTP payload types 98 and 99 as being "vbd" codecs, with
PCMU and G726-32 encodings, and with echo cancellation off and on respectively.
Kumar Informational 2
Generic Format-Specific Parameter March 2002
Note that the static payload type 2 (G726-32) does not appear in the media line
in this case. The only permitted voice encodings are PCMU (payload type 0) and
G728 (payload type 15).
When both voice and voiceband data payload types are distinctly earmarked for a
session at session establishment, a transmitter may switch from a voice payload
type (0 or 15 in the example above) to a voiceband data payload type (98 or 99
in the example above) when it detects an appropriate event such as an ANS or
ANSAM as defined in ITU V.25 and ITU V.8 respectively. When the receiving
gateway or endpoint sees a voiceband data payload type (e.g. 98 in the example
above), it recognizes this as a voiceband data codec (with PCMU encoding) and
adjusts the jitter buffer accordingly. In this example, it also turns echo
cancellation off it is not already off.
The packet format defined in RFC 2198 can be used with a voiceband data codec
for greater reliability by virtue of redundant transmission. A dynamic payload
type is defined for the encoding name "red". The encapsulated voiceband data
packets are, in this case, staggered in time (earlier and later packets combined
in an RFC 2198 composite packet). In the following example media description:
m=audio 3456 RTP/AVP 0 98 100
a=rtpmap:98 PCMU/8000
a=gfmtp:98 vbd=on;ecan=off
a=rtpmap:100 red/8000
a=fmtp:100 98/98
a dynamic payload type of 100 is associated with RFC 2198 packets. A 'fmtp' line
indicates that these RFC 2198 packets encapsulate two voiceband data payloads,
each with payload type 98. The encapsulated packets are staggered in time
(i.e. earlier and later packets combined in an RFC 2198 composite packet).
5. Acknowledgements
Henning Schulzrinne and Steven Casner for the idea of this new, generic SDP
attribute. Bill Foster and Flemming Andreasen for their energy put in pursuing
the logical antecedents of this draft [1].
8. References
[1] Voiceband Data Media Format, draft-foster-mmusic-vbdformat-01.txt,
Bill Foster, Rajesh Kumar and Flemming Andreasen.
[2] An RTP Payload Format for Generic Forward Error Correction, RFC 2733,
Rosenberg and Schulzrinne.
[3] M. Handley, V. Jacobson, SDP: Session Description Protocol, RFC
2327.
[4] H. Schulzrinne, RTP Profile for Audio and Video Conferences with
Minimal Control, RFC 1890.
Kumar Informational 3
Generic Format-Specific Parameter March 2002
[5] http://www.iana.org/assignments/rtp-parameters.
[6] C. Perkins et al, RTP payload for redundant audio data, RFC 2198.
[7] MIME Type Registration of RTP Payload Formats,
draft-ietf-avt-rtp-mime-06.txt, Casner, S. and Hoschka, P.
9. Author's Addresses
Rajesh Kumar
Cisco Systems
170 West Tasman Dr
San Jose, CA
Phone: +1 408 527 0811
Email: rkumar@cisco.com
7. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kumar Informational 4