Internet Engineering Task Force Rajesh Kumar Internet Draft Cisco Systems Document: June 1, 2002 Category: Informational Expires: December 1, 2002 Generic Format 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 There may be a need, in some applications, to describe a format (e.g. payload type) with parameters that are not part of its standard (e.g. MIME) definition. An example is a boolean parameter, 'vbd', that associates a dynamic payload type with voiceband data treatment. This internet draft defines a new SDP attribute to convey such parameters. Values of this parameter will need to be registered with IANA. The name of this attribute, 'gfmtp', is tentative. Suggestions for a better name are requested. This document may be folded into another document such as the new SDP specification. Kumar Informational 1 Generic Format-Specific Parameter April 2002 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] 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. 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: 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 a parameter like 'vbd', this might result in some degradation. This document defines the boolean (yes/no) parameter 'vbd' (voiceband data) that can be used with the 'gfmtp' attribute. Other parameter definitions are possible. Standard values must be registered with IANA. Kumar Informational 2 Generic Format-Specific Parameter June 2002 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 a=rtpmap:99 G726-32/8000 a=gfmtp:99 vbd=on This specifies dynamic RTP payload types 98 and 99 as being "vbd" codecs, with PCMU and G726-32 encodings. 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. 5. Acknowledgements Steven Casner, Henning Schulzrinne and Colin Perkins 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]. Flemming Andreasen for suggesting the genericization of this parameter beyond RTP payload type. 6. 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 June 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. 7. Author's Addresses Rajesh Kumar Cisco Systems 170 West Tasman Dr San Jose, CA Phone: +1 408 527 0811 Email: rkumar@cisco.com 8. 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. Kumar Informational 4 Generic Format-Specific Parameter June 2002 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kumar Informational 5