Internet Engineering Task Force Rajesh Kumar Internet Draft Cisco Systems Document: August 17, 2002 Expires: February 17, 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.................................................................2 2. Conventions used in this document........................................2 3. Introduction.............................................................2 4. Syntax of the 'gfmtp' attribute..........................................2 5. ABNF Grammar for 'gfmtp' attribute.......................................3 6. Compatibility Considerations.............................................4 7. Security Considerations..................................................4 8. IANA considerations......................................................4 9. Acknowledgements.........................................................5 10. References...............................................................5 R.Kumar August 2002 Page 1 Generic Format Parameter 1. Abstract A method of associating, with a format, parameters that are not part of its standard (e.g. MIME) definition is described. This is done through a new SDP attribute, 'gfmtp', which is syntactically modeled after the existing 'fmtp' attribute. A new IANA registry for parameters used with the 'gfmtp' attribute is defined. 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 The 'gfmtp' (generic format parameter) SDP attribute defined in this document is used to associate, with a format (such as PCMU), parameters (such as voiceband data treatment) that are not included in its standard MIME definition. Parameters that are included in the standard MIME definition are expressed in SDP through the 'fmtp' attribute [3, 7]. The parameters expressed through the 'gfmtp' attribute can be generically applied to a broad range of payload formats. For example, the ITU V.150 modem- over-IP standardization work [1] has identified a need to selectively associate RTP payload types with voiceband data (VBD) processing. VBD treatment may include the use of large, fixed length jitter buffers (as opposed to smaller, adaptive jitter buffers) and the absence of packet loss concealment techniques. Some RTP formats that may be candidates for VBD treatment are PCMU, PCMA, G726-40 and G726-32. However, this association is made selectively, on a call- by-call basis. Further, two payload types may be mapped into the same RTP format (e.g. PCMU) such that one is earmarked for VBD treatment, while another is not. 4. Syntax of the 'gfmtp' attribute This section contains a verbal description of the syntax of the 'gfmtp' attribute, and an example of its use. The precise ABNF syntax for the 'gfmtp' attribute is found in Section xxx. The SDP attribute, gfmtp, is defined as: a=gfmtp: is represented as a semicolon-separated list of "subparameter=value" pairs. The format may be an RTP payload type. These are referred to as "subparameters" in this document since they are nested within the 'gfmtp' attribute R.Kumar August 2002 Page 2 Generic Format Parameter For example, the subparameter 'vbd', indicating whether VBD treatment is applied of not, is a boolean with possible values of "yes" and "no". A value of "no" is equivalent to omitting the subparameter. Thus, m=audio 3456 RTP/AVP 0 15 a=gfmtp:0 vbd=yes enables VBD treatment for the static RTP payload type of 0 (PCMU). The following example shows a static and a dynamic payload type associated with the PCMU format. Only the dynamic payload type, 98, is earmarked for VBD treatment. m=audio 3456 RTP/AVP 0 15 98 a=rtpmap:98 PCMU/8000 a=gfmtp:98 vbd=yes The following example reverse the VBD association. Of the static and dynamic payload types associated with PCMU, only the static payload type, 0, is earmarked for VBD treatment. 5. ABNF Grammar for 'gfmtp' attribute This appendix provides an Augmented BNF (ABNF) grammar for the 'gfmtp' attribute defined in this document. ABNF is defined in rfc2234. RFC 2327 [2] generically defines attributes as follows: attribute-fields = *("a=" attribute CRLF) attribute = (att-field ":" att-value) | att-field For the 'gfmtp' attribute, a special case of this ABNF syntax may be stated as follows: gfmtp-attribute-field = "a=" gftmp-attribute CRLF gfmtp-attribute = "gfmtp" ":" gfmtp-value gfmtp-value = 1*(gfmtp-subparameter) gfmtp-subparameter = gfmtp-subparameter-name "=" gfmtp-subparameter-value gfmtp-subparameter-name = token gfmtp-subparameter-value = byte-string token = 1*(token-char) token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E ; definition from RFC 2045 - ; "any (US-ASCII) CHAR except SPACE, CTLs, ; or tspecials". ; the tspecials are ()<>@,;: byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF R.Kumar August 2002 Page 3 Generic Format Parameter 6. Compatibility Considerations Existing SDP parsers should be able to ignore 'gfmtp' if it is an unknown attribute [2]. Note that applications may require that a minimum number of suitably earmarked payload types be declared and supported. For example, an ITU V.150 application must include VBD-marked PCMU and PCMA formats in an an SDP offer [3], and at least one VBD-marked RTP format (which need not be PCMA or PCMU) in an SDP answer. Such application-specific requirements do not impact parser-level SDP compatibility. 7. Security Considerations This document does not impose any security requirement over and above those for SDP session descriptions [2]. In a nutshell, the 'gfmtp' attribute, like the rest of the session, SHOULD NOT be trusted unless it has been obtained by an authenticated transport protocol from a trusted source. If the session description containing this line does not inherit proper authentication form a transport mechanism, certain precautions are in order. SDP parsers MUST NOT be able to start software except that which is specifically configured as appropriate software to participate in multimedia sessions to which the end user has consented. Firewalls which parser an SDP description should not open a hole in the firewall for unicast data streams in response to a 'gfmtp' attribute unless the session description has emanated form inside the firewall. For multicast data streams, such action should be contingent on administrative policy. 8. IANA considerations Besides registering 'gfmtp' as an SDP attribute, it is necessary to create a new registry for 'gfmtp' subparameter names. Registration applications must include: - contact name, email address and telephone number. - 'gfmtp' subparameter name being registered. This must comply with the ABNF definition of gfmtp-subparameter-name in Section xxx. - a one paragraph explanation of the purpose of the registered name. - reference to a specification approved by an accredited standards organization such as the IETF. This specification must describe the syntax and semantics of the values that may be assigned to the subparameter. R.Kumar August 2002 Page 4 Generic Format Parameter 9. Acknowledgements Steven Casner, Henning Schulzrinne and Colin Perkins for the idea of this new, generic SDP attribute. Colin Perkins for suggesting the IANA registry mechanism needed with the 'gfmtp' attribute. Bill Foster and Flemming Andreasen for their energy put in pursuing the logical antecedents of this draft. Flemming Andreasen for suggesting that the use of the 'gfmtp' attribute may be made generic beyond its use with an RTP payload type. 10. References [1] ITU V.150.1, Procedures for the end-to-end connection of V-series DCEs over an IP Network, work-in-progress, http://ftp.tiaonline.org/TR-30/TR301/Public. [2] M. Handley, V. Jacobson, SDP: Session Description Protocol, RFC 2327. [3] An Offer/Answer Model with the Session Description Protocol (SDP), RFC 3264. 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 R.Kumar August 2002 Page 5 Generic Format Parameter 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. R.Kumar August 2002 Page 6