Internet DRAFT - draft-andreasen-mmusic-sdp-simcap

draft-andreasen-mmusic-sdp-simcap





MMUSIC Working Group                                       F. Andreasen 
Internet-Draft                                            Cisco Systems 
Document: draft-andreasen-mmusic-sdp-simcap-05.txt        February 2002 
Category: Standards Track                                               
 
 
                   SDP Simple Capability Declaration 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1].  
    
   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 
    
   This document defines a set of Session Description Protocol (SDP) 
   attributes that enables SDP to provide a minimal and backwards 
   compatible capability declaration mechanism. Such capability 
   declarations can be used as input to a subsequent session 
   negotiation, which is done by means outside the scope of this 
   document. This provides a simple and limited solution to the general 
   capability negotiation problem being addressed by the next 
   generation of SDP, also known as SDPng. 
    
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 [2]. 
    
3. Introduction 
    
   The Session Description Protocol (SDP) [3] describes multimedia 
   sessions for the purposes of session announcement, session 
   invitation, and other forms of multimedia session initiation. SDP 
   was not intended to provide capability negotiation, however as the 
   need for this has become increasingly important, work has begun on a 
   "next generation SDP" (SDPng) [4,5] that supports both session 
   description and capability negotiation. SDPng is not anticipated to 
  
Andreasen       Standards Track - Expires August 2002        [Page 1] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
   be backwards compatible with SDP and work on SDPng is currently in 
   the early stages. However, several other protocols, e.g. SIP [6] and 
   MGCP [7], use SDP and are likely to continue doing so for the 
   foreseeable future. Nevertheless, in many cases these signaling 
   protocols have an urgent need for some limited form of capability 
   negotiation.  
    
   For example, an endpoint may support G.711 audio (over RTP) as well 
   as T.38 fax relay (over UDP or TCP). Unless the endpoint is willing 
   to support two media streams at the same time, this cannot currently 
   be expressed in SDP. Another example involves support for multiple 
   codecs. An endpoint indicates this by including all the codecs in 
   the "m=" line in the session description. However, the endpoint 
   thereby also commits to simultaneous support for each of these 
   codecs. In practice, DSP memory and processing power limitations may 
   not make this feasible.  
    
   As noted in [4], the problem with SDP is, that media descriptions 
   are used to describe session parameters as well as capabilities 
   without a clear distinction between the two.  
    
   In this document, we define a minimal and backwards compatible 
   capability declaration feature in SDP by defining a set of new SDP 
   attributes. Together, these attributes define a capability set, 
   which consists of a capability set sequence number followed by one 
   or more capability descriptions. Each capability description in the 
   set contains information about supported media formats, however the 
   endpoint is not committing to use any of these. In order to actually 
   use a declared capability, session negotiation will have to be done 
   by means outside the scope of this document, e.g., using the 
   offer/answer model [8]. 
    
   It should be noted, that the mechanism is not intended to solve the 
   general capability negotiation problem targeted by SDPng. It is 
   merely intended as a simple and limited solution to the most urgent 
   problems facing current users of SDP.  
    
4. Simple Capability Description Attributes 
    
   The SDP Simple Capability Description (simcap) is defined by a set 
   of SDP attributes. Together, these attributes form a capability set 
   which describes the complete media capabilities of the endpoint. Any 
   previous capability sets issued by the endpoint for the session in 
   question no longer apply. The capability set consists of a sequence 
   number and one or more capability descriptions. Each such capability 
   description describes the media type and media formats supported and 
   may include one or more capability parameters to further define the 
   capability. A session description MUST NOT contain more than one 
   capability set, however the capability set can describe capabilities 
   at both the session and media level. Capability descriptions 
   provided at the session level apply to all media streams of the 
   media type indicated, whereas capability descriptions provided at 
   the media level apply to that particular media stream only. We refer 
  
Andreasen       Standards Track - Expires August 2002        [Page 2] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
   to these respectively as session capabilities and media stream 
   capabilities. A media stream capability may or may not be of the 
   same media type as the media stream to which it applies.  
    
   The capability set MUST begin with a single sequence number followed 
   by one or more capability descriptions listing all media formats the 
   endpoint is currently able and willing to support. More 
   specifically, if a media format is included in a media ("m=") line, 
   then by definition the media format MUST be included in either a 
   session capability or a media stream capability for that media line. 
   The endpoint MAY include additional media formats in a capability if 
   it is capable of supporting the media format in a session with its 
   peer. An endpoint MUST NOT include capabilities it knows it cannot 
   use in a particular session. An endpoint receiving a capability set 
   from another endpoint MAY use any of the media formats included in 
   that capability set in a later attempt to negotiate media streams 
   with the other endpoint, e.g., using the offer/answer model [8]. If 
   a new capability set is received from the other endpoint, the old 
   capability set MUST NOT be used any longer. Session capabilities can 
   be used for any media streams of the indicated media type, whereas 
   media stream capabilities can only be used for their associated 
   media line. However, an endpoint receiving a capability set with a 
   given media format MUST NOT assume that a subsequent attempt to 
   negotiate a media stream using just this media format will succeed.  
    
   The individual capability descriptions in a capability set can be 
   provided contiguously or they can be scattered throughout the 
   session description. The first capability description however MUST 
   follow immediately after the sequence number.  
    
   The sequence number is on the form: 
    
     a=sqn: <sqn-num>  
    
   where <sqn-num> is an integer between 0 and 255 (both included). The 
   initial sequence number MUST be 0 (zero) and it MUST be incremented 
   by 1 modulo 256 with each new capability set issued by the endpoint. 
   Receivers may not necessarily see all capability sets issued and 
   hence MUST NOT reject a capability set due to gaps in sequence 
   numbers. The sequence number MUST either be provided as a session-
   level or media-level attribute, however there MUST NOT be more than 
   one occurrence of the sequence number attribute in the session 
   description (since there cannot be more than one capability set).  
    
   Each capability description in the capability set is on the form: 
    
     a=cdsc: <cap-num> <media> <transport> <fmt list>  
    
   where <cap-num> is an integer between 1 and 255 (both included) used 
   to number the capabilities , and <media>, <transport>, and <fmt 
   list> are defined as in the SDP "m=" line. The capability 
   description refers to a send and receive capability by default. When 
   generating a capability set, the capability number MUST start with 1 
  
Andreasen       Standards Track - Expires August 2002        [Page 3] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
   in the first capability description, and be incremented by the 
   number of media formats in the <fmt list> for each subsequent 
   capability description. The media formats in the <fmt list> are 
   numbered from left to right. Receivers of a capability set however 
   MUST NOT reject capability descriptions due to gaps in the 
   capability numbers. The capability number provides a convenient 
   handle within the context of the capability set (as referenced by 
   the sequence number) which may be used to reference a particular 
   capability by means outside of this specification.  
    
   A capability description can include one or more capability 
   parameter lines on the form: 
    
     a=cpar: <cap-par> 
     a=cparmin: <cap-par> 
     a=cparmax: <cap-par> 
    
   where <cap-par> is either bandwidth information ("b=") or an 
   attribute ("a=") in its full '<type>=<value>' form (see [3]). A 
   capability parameter line provides additional parameters for the 
   preceding "cdsc" attribute line. Capability parameter lines for a 
   capability description SHOULD immediately follow the "cdsc" line 
   they refer to. Nevertheless, the capability description includes all 
   capability parameter lines until the next capability description 
   ("cdsc") or media ("m=") line in the session description. 
    
   The "cpar" attribute should normally be used when capability 
   parameter values are to be specified. When provided, it means that 
   the endpoint is declaring that it supports the media formats in the 
   preceding "cdsc" line in accordance with the <cap-par> value 
   specified. This can for example be used to specify "fmtp" 
   parameters. If a session negotiation is attempted without 
   considering the <cap-par> value, it may fail due to lack of endpoint 
   support. A capability description may contain zero, one, or more 
   "cpar" attribute lines describing either the same or different 
   parameters. Describing the same parameter more than once can be used 
   to specify alternatives. 
    
   Where a minimum numerical value is to be specified, the "cparmin" 
   attribute should be used. There may be zero, one, or more "cparmin" 
   attribute lines in a capability description, however a given 
   parameter MUST NOT be described by a "cparmin" attribute more than 
   once. 
    
   Where a maximum numerical value is to be specified, the "cparmax" 
   attribute should be used. There may be zero, one, or more "cparmax" 
   attribute lines in a capability description, however a given 
   parameter MUST NOT be described by a "cparmax" attribute more than 
   once. 
    
   Ranges of numerical values can be expressed by using a "cparmin" and 
   a "cparmax" attribute for a given parameter. It follows from the 

  
Andreasen       Standards Track - Expires August 2002        [Page 4] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
   previous rules, that only a single range can be specified for a 
   given parameter.  
    
   Capability descriptions may be provided at both the session-level 
   and media-level. A capability description provided at the session-
   level applies to all the media streams of the indicated media type 
   in the session description. A capability description provided at the 
   media-level only applies to that particular media stream (regardless 
   of media type). If a capability description with media type X is 
   provided at the session-level, and there are no media streams of 
   type X in the session description, then it is undefined which of the 
   media streams the capability description applies to (except if there 
   is only one media stream). It is therefore RECOMMENDED, that such 
   capabilities are provided at the media-level instead. 
    
   Below we show an example session description using the above simple 
   capability negotiation mechanism: 
    
     v=0 
     o=- 25678 753849 IN IP4 128.96.41.1 
     s=  
     c=IN IP4 128.96.41.1 
     t=0 0 
     m=audio 3456 RTP/AVP 18 96 
     a=rtpmap:96 telephone-event 
     a=fmtp:96 0-15,32-35 
     a=sqn: 0 
     a=cdsc: 1 audio RTP/AVP 0 18 96 
     a=cpar: a=fmtp:96 0-16,32-35 
     a=cdsc: 4 image udptl t38 
     a=cdsc: 5 image tcp t38 
    
    
   The sender of this session description is currently prepared to send 
   and receive G.729 audio as well as telephone-events 0-15 and 32-35. 
   The sender is furthermore capable of supporting:  
    
   *  PCMU encoding for the audio media stream,  
   *  telephone events 0-16 and 32-35, 
   *  T.38 fax relay using udp or tcp (see [9]). 
    
   Note, that the first capability number specified is 1, whereas the 
   next is 4 since three media formats were included in the first 
   capability description. Also note, that the rtpmap for payload type 
   96 was not included in the capability description, as it was already 
   specified for the media ("m=") line. Conversely, it would of course 
   not have been valid to provide the rtpmap in the capability 
   description and then omit the "a=rtpmap" line. 
    
   Below, we show another example of the simple capability negotiation 
   mechanism, this time with multiple media streams:  
    

  
Andreasen       Standards Track - Expires August 2002        [Page 5] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
     v=0 
     o=- 25678 753849 IN IP4 128.96.41.1 
     s=  
     c=IN IP4 128.96.41.1 
     t=0 0 
     m=audio 3456 RTP/AVP 18  
     a=sqn: 0 
     a=cdsc: 1 audio RTP/AVP 0 18 
     m=video 3458 RTP/AVP 31 
     a=cdsc: 3 video RTP/AVP 31 34 
    
   The sender of this session description is currently prepared to send 
   and receive G.729 audio and H.261 video. The sender is furthermore 
   capable of supporting:  
    
   *  PCMU encoding for the audio media stream, 
   *  H.263 for the video media stream.  
    
   Note, that the first capability number specified is 1, whereas the 
   next is 3 since two media formats were included in the first 
   capability description. Also note, that the sequence number applies 
   to the entire capability set, i.e. both audio and video, and hence 
   is only supplied once. Finally, note that the media formats 18 and 
   31 are listed in both the media lines and the capability set as 
   required. The above session description could equally well have been 
   supplied as follows: 
    
     v=0 
     o=- 25678 753849 IN IP4 128.96.41.1 
     s=  
     c=IN IP4 128.96.41.1 
     t=0 0 
     a=sqn: 0 
     a=cdsc: 1 audio RTP/AVP 0 18 
     a=cdsc: 3 video RTP/AVP 31 34 
     m=audio 3456 RTP/AVP 18  
     m=video 3458 RTP/AVP 31 
     
   i.e., with the capability set provided at the session-level. 
    
5. Security Considerations 
 
   The addition of the simple capability negotiation attributes to SDP 
   is not believed to cause security issues beyond those discussed in 
   RFC 2327. 
    
6. IANA Considerations 
    
   This document defines the following new SDP parameters of type "att-
   field" (attribute names): 
    
   Attribute name:      sqn 
   Long form name:      Sequence number. 
  
Andreasen       Standards Track - Expires August 2002        [Page 6] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
   Type of attribute:   Session-level and media-level. 
   Subject to charset:  No.  
   Purpose:             Capability set numbering. 
   Appropriate values:  See Section 4.   
    
    
   Attribute name:      cdsc 
   Long form name:      Capability description. 
   Type of attribute:   Session-level and media-level. 
   Subject to charset:  No.  
   Purpose:             Describe capabilities in a capability set. 
   Appropriate values:  See Section 4.  
    
    
   Attribute name:      cpar 
   Long form name:      Capability parameter line. 
   Type of attribute:   Session-level and media-level. 
   Subject to charset:  No.  
   Purpose:             Provide capability description parameters. 
   Appropriate values:  See Section 4.  
    
    
   Attribute name:      cparmin 
   Long form name:      Minimum capability parameter line. 
   Type of attribute:   Session-level and media-level. 
   Subject to charset:  No. 
   Purpose:             Provide minimum capability description  
                        parameters. 
   Appropriate values:  See Section 4.  
    
    
   Attribute name:      cparmax 
   Long form name:      Maximum capability parameter line. 
   Type of attribute:   Session-level and media-level. 
   Subject to charset:  No.  
   Purpose:             Provide maximum capability description  
                        parameters. 
   Appropriate values:  See Section 4.  
    
7. References 
 
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, Internet Engineering Task Force, October 1996. 
    
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, Internet Engineering Task Force, March 
      1997. 
    
   3  M. Handley and V. Jacobson, "SDP: session description protocol", 
      Request for Comments 2327, Internet Engineering Task Force, April 
      1998. 
    
 
  
Andreasen       Standards Track - Expires August 2002        [Page 7] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
 
   4  Kutscher, Ott, Bormann, Curcio, "Requirements for Session 
      Description and Capability Negotiation", Internet-Draft, Internet 
      Engineering Task Force, April 2001. Work in Progress. 
    
   5  Kutscher, Ott, Borman, "Session Description and Capability 
      Negotiation", Internet-Draft, Internet Engineering Task Force, 
      November 2001. Work in Progress. 
    
   6  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 
      session initiation protocol", Request for Comments 2543, Internet 
      Engineering Task Force, March 1999. 
    
   7  Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, 
      "Media Gateway Control Protocol (MGCP) Version 1.0", Request for 
      Comments 2705, Internet Engineering Task Force, October 1999. 
    
   8  Rosenberg, J., Schulzrinne, H., "An Offer/Answer Model with SDP", 
      Internet-Draft, Internet Engineering Task Force, February, 2002. 
      Work in Progress. 
    
   9  ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment 
      Procedures".   
    
8. Acknowledgments 
    
   This work draws upon the ongoing work on SDPng in the IETF MMUSIC 
   Working Group; in particular [4]. Furthermore this work was inspired 
   by the CableLabs PacketCable project. The author would like to 
   recognize and thank Joerg Ott and Jonathan Rosenberg who provided 
   many detailed comments and suggestions to improve this 
   specification. Colin Perkins, Orit Levin and Tom Taylor provided 
   valuable feedback as well.  
    
9. Author's Address 
    
   Flemming Andreasen 
   Cisco Systems 
   499 Thornall Street, 8th floor 
   Edison, NJ 
   Email: fandreas@cisco.com  












  
Andreasen       Standards Track - Expires August 2002        [Page 8] 

Internet-Draft    SDP Simple Capability Declaration     February 2002 
 
 
    
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2002). 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. 
    


















  
Andreasen       Standards Track - Expires August 2002        [Page 9]