Internet Engineering Task Force Rajesh Kumar Internet Draft Cisco Systems Document: September 15, 2002 Expires: March 15, 2003 SDP attribute for qualifying Media Formats with Generic Parameters 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. Abstract This document defines one SDP attribute: 'gpmd', or general-purpose media descriptor. This attribute allows the use of generic parameters to qualify media formats. These generic parameters are not part of the standard (e.g. MIME) definition of the media format. The syntax and semantics of the 'gpmd' attribute and possible generic parameters that constitute it are defined, along with guidelines for the definition and registration of these generic parameters. R.Kumar September 2002 Page 1 General-Purpose Media Descriptor 1. Introduction.............................................................2 2. Terminology..............................................................2 3. Purpose and semantics of the 'gpmd' attribute............................3 4. Syntax of the 'gpmd' attribute...........................................3 5. ABNF Grammar for 'gpmd' attribute........................................4 6. An exemplary 'gpmd'-enclosed parameter, 'vbd'............................5 7. Security Considerations..................................................5 8. IANA considerations......................................................6 9. Acknowledgements.........................................................7 10. References...............................................................7 11. Author's Address.........................................................7 1. Introduction In some applications, there is a need to qualify media formats with generic parameters. As generic parameters, these are included in the format-specific parameters that are an integral part of the standard definition of the media format. For example, an endpoint or gateway might want to indicate that an RTP payload type will be treated, for the duration of a session, as containing a modulated data signal. Other such cases might arise in the future. This creates a two-fold need: 1. An SDP mechanism to bind, on a per-session basis, values of one or more generic parameters to a media format. 2. A mechanism for defining and registering such parameters in the future. The proposed solution is to define, for SDP, a general-purpose media descriptor that can flexibly contain one or more of these generic parameters. An endpoint or gateway may choose which generic parameters to advertise using this general-purpose media descriptor. Therefore, the proposed solution should allow position-independent parsing of these generic parameters. This requires that these generic parameters be expressed in the = form. This internet draft obsoletes its predecessors, which addressed the same problem: - draft-rajeshkumar-mmusic-gfmtp-03.txt - draft-foster-mmusic-vbdformat-01.txt (expired) 2. Terminology 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. R.Kumar September 2002 Page 2 General-Purpose Media Descriptor 3. Purpose and semantics of the 'gpmd' attribute The 'gpmd' attribute defined in this document is a media-level attribute. It is to be used when an endpoint or gateway wishes to bind, to a media format, a value of one of the generic parameters associated with the 'gpmd' attribute. An extensible registry of these parameters and their possible values will be provided (details in Section 8.2). Like other SDP attributes, the 'gpmd' attribute is optional. SDP parsers that do not understand it understand it can ignore it. The same is true for each generic parameter enclosed within the 'gpmd' attribute. SDP parsers may ignore these as well. An application that uses SDP may define certain attributes as mandatory within the context of that application. This is also true for the generic parameters enclosed within the 'gpmd' attribute. Being mandatory in the context of an application does not clash with their being completely optional at the SDP parser level. This, each application must decide what to do if certain generic parameters enclosed within the 'gpmd' attribute are not understood. Since an application is will define required generic parameters beforehand, the most likely approach is to ignore unknown parameters enclosed within the 'gpmd' attribute. The parameters enclosed within a 'gpmd' attribute line are different from the parameters enclosed within a 'fmtp' line in the following way: The parameters enclosed within a 'fmtp' line are found in the standard definition (e.g. MIME registration) of that format. Some of these parameters are mandatory, while others are optional. By contrast, the parameters that may be enclosed within a 'gpmd' line are not part of the standard definition (e.g. MIME registration) of the media format, to which they are dynamically bound, on a per-session basis. These parameters are maintained in a separate, extensible registry (Section 8.2). The definition of a 'gpmd'-enclosed parameter within this registry will indicate the range of media formats which may be qualified by it. All 'gpmd'-enclosed parameters are optional at the SDP parser level, though some applications may mandate particular parameters. 4. Syntax of the 'gpmd' attribute This section contains a verbal description of the syntax of the 'gpmd' attribute, and an example of its use. The precise ABNF syntax for the 'gpmd' attribute is found in Section 5. The SDP attribute, gpmd, is defined as: a=gpmd: is represented as a semicolon-separated list of R.Kumar September 2002 Page 3 General-Purpose Media Descriptor = pairs. For example, the generic parameter 'vbd' (Section 6) is a boolean which may be associated with any RTP payload type. Thus, m=audio 3456 RTP/AVP 0 15 a=gpmd:0 vbd=yes enables voice band data treatment for the static RTP payload type of 0 (PCMU). Note that need not be an RTP payload type. It is permissible to use any value of that appears in an 'm=' line as long as the definition of each generic parameter (Section 8.2) allows it to be used to qualify that media format. Thus, a hypothetical generic parameter, 'someParameter', may be enclosed in a 'gpmd' attribute associated with the format 'wb' (whiteboard) as follows: m=application 3456 udp wb a=gpmd:wb someParameter=someValue The 'gpmd' attribute is charset-independent. This property is inherited by all generic parameters enclosed within the 'gpmd' attribute. 5. ABNF Grammar for 'gpmd' attribute This section provides an Augmented BNF (ABNF) grammar [4] for the 'gpmd' attribute defined in this document. Here, generic parameters that may be enclosed within the 'gpmd' attribute are referred to as 'subparameters'. RFC 2327 [2] generically defines attributes as follows: attribute-fields = *("a=" attribute CRLF) attribute = (att-field ":" att-value) | att-field For the 'gpmd' attribute, a special case of this ABNF syntax may be stated as follows: gpmd-attribute-field = "a=" gpmd-attribute CRLF gpmd-attribute = "gpmd" ":" gpmd-value gpmd-value = 1*(gpmd-subparameter) gpmd-subparameter = gpmd-subparameter-name "=" gpmd-subparameter-value gpmd-subparameter-name = 1*(alpha-numeric) gpmd-subparameter-value = byte-string alpha-numeric = ALPHA / DIGIT ; external reference: ; ALPHA and DIGIT from RFC 2234 [4] byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF R.Kumar September 2002 Page 4 General-Purpose Media Descriptor 6. An exemplary 'gpmd'-enclosed parameter, 'vbd' This section describes a generic parameter, 'vbd', that may be enclosed in the 'gpmd' attribute. The registration of the this parameter is addressed in Section 8.3. The generic parameter, 'vbd', indicates voice band data. It is a boolean that may be assigned the values of "yes" or "no". A value of "no" is equivalent to omitting the 'vbd' parameter. Using this generic parameter, any RTP payload type associated with audio media may be earmarked for voice band data treatment. In practice, applications are likely to use one of the following audio media formats for the carriage of voice band data signals: PCMU, PCMA, G726-40 and G726-32. Voice band data treatment implies the use of large, fixed length jitter buffers (as opposed to smaller, adaptive jitter buffers) and the absence of packet loss concealment techniques. Note that an RTP format (e.g. PCMU) may be associated, in the context of a session, with multiple payload types. For a given RTP format, one of these may be a static payload type, while the others are dynamically assigned payload types. Regardless of whether a given payload type is static or dynamic, it may be earmarked for voice band data treatment. Without the parameter 'vbd', the payload type, whether static or dynamic, is insufficient to determine whether a modem signal being encoded or not. 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 voice band data treatment. m=audio 3456 RTP/AVP 0 15 98 a=rtpmap:98 PCMU/8000 a=gpmd:98 vbd=yes The following example reverses the association of payload type with voice band data. Of the static and dynamic payload types associated with PCMU, only the static payload type, 0, is earmarked for VBD treatment. m=audio 3456 RTP/AVP 0 15 98 a=gpmd:0 vbd=yes a=rtpmap:98 PCMU/8000 7. Security Considerations This document does not impose any security requirement over and above those for SDP session descriptions [2]. In a nutshell, the 'gpmd' 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 from 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 parse an SDP description should not open a R.Kumar September 2002 Page 5 General-Purpose Media Descriptor hole in the firewall for unicast data streams in response to a 'gpmd' 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 Three IANA actions are indicated in this document: - The registration of 'gpmd' as an SDP attribute, (Section 8.1) - The creation of a new registry for 'gpmd'-enclosed generic parameters (Section 8.2), - The registration of 'vbd' as a generic parameter within this registry (Section 8.3). 8.1 Registration of the SDP attribute 'gpmd' This section follows the rules of RFC 2327 in describing the IANA registration information for the SDP attribute 'gpmd'. Source document: This document Contact: Section 11 of this document Attribute name (SDP): gpmd Attribute name(English): General-purpose media descriptor Attribute type: Media-level Charset: Not subject to charset. Purpose of attribute: Section 3 of this document Attribute values: Section 4 of this document 8.2 Parameter registry for 'gpmd'-enclosed parameters It is required that all new, non-experimental parameters that may be enclosed within the 'gpmd' attribute be registered with the IANA. Vendors may define use unregistered, experimental parameters that being with "X-". The "X-" prefix is meant to prevent clashes with parameters that are currently registered or may be registered in the future. New 'gpmd'-enclosed parameters must be described in a specification ("source document") approved by an accredited standards organization such as the IETF. This specification must include: - The alphanumeric character string that indicates the parameter name. No characters except alphabets and digits are allowed in the name (Section 5). - The range of values and the default value for the parameter. R.Kumar September 2002 Page 6 General-Purpose Media Descriptor - A one paragraph description of the meaning (semantics) of the parameter. What does it represent? What effect do its values have on media stream processing? What media formats can it be applied to? - Contact name, email address and telephone number. 8.3 IANA Registration of the 'gpmd'-enclosed parameter 'vbd' This section follows the rules of Section 8.1 in describing the IANA registration information for the parameter 'vbd'. Source document: This document Parameter name: vbd Range of values: "yes", "no" without the quotes Parameter description: Section 6 of this document Contact: Section 11 of this document 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 'gpmd' 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 'gpmd' 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. [4] Augmented BNF for Syntax Specifications: ABNF, RFC 2234. 11. Author's Address Rajesh Kumar Cisco Systems R.Kumar September 2002 Page 7 General-Purpose Media Descriptor 170 West Tasman Dr San Jose, CA Phone: +1 408 527 0811 Email: rkumar@cisco.com 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. R.Kumar September 2002 Page 8