Internet DRAFT - draft-rajeshkumar-mmusic-gfmtp

draft-rajeshkumar-mmusic-gfmtp






 
 
 
  
  
  
Internet Engineering Task Force                                    Rajesh Kumar    
Internet Draft                                                    Cisco Systems    
Document: <draft-rajeshkumar-mmusic-gfmtp-03.txt>               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:<format><subparameter list>   
        
<subparameter list> 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