Session Description Protocol (SDP) Simple Capability Declaration
RFC 3407

Andreasen                   Standards Track                     [Page 4]
RFC 3407           SDP Simple Capability Declaration        October 2002

   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
   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 declaration 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

Andreasen                   Standards Track                     [Page 5]
RFC 3407           SDP Simple Capability Declaration        October 2002

   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 declaration
   mechanism, this time with multiple media streams:

     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 have equally been
   supplied as follows:

Andreasen                   Standards Track                     [Page 6]
RFC 3407           SDP Simple Capability Declaration        October 2002

     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.

4. Security Considerations

   Capability negotiation of security-sensitive parameters is a delicate
   process, and should not be done without careful evaluation of the
   design, including the possible susceptibility to downgrade attacks.
   Use of capability re-negotiation may make the session susceptible to
   denial of service, without design care as to authentication.

5. IANA Considerations

   This document defines the following new SDP parameters of type "att-
   field" (attribute names):

   Attribute name:      sqn
   Long form name:      Sequence number.
   Type of attribute:   Session-level and media-level.
   Subject to charset:  No.
   Purpose:             Capability set numbering.
   Appropriate values:  See Section 3.

   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 3.

   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 3.

Andreasen                   Standards Track                     [Page 7]
RFC 3407           SDP Simple Capability Declaration        October 2002

   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 3.

   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 3.

6. Normative References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

   [3] Handley, M. and V. Jacobson, "SDP: session description protocol",
       Request for Comments 2327, April 1998.

7. Informative References

   [4] Kutscher, Ott, Bormann and Curcio, "Requirements for Session
       Description and Capability Negotiation", Work in Progress.

   [5] Kutscher, Ott and Borman, "Session Description and Capability
       Negotiation", Work in Progress.

   [6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
       "SIP: session initiation protocol", RFC 2543, March 1999.

   [7] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett,
       "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705,
       October 1999.

   [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
       SDP", Work in Progress.

   [9] ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment
       Procedures".

Andreasen                   Standards Track                     [Page 8]
RFC 3407           SDP Simple Capability Declaration        October 2002

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                     [Page 9]
RFC 3407           SDP Simple Capability Declaration        October 2002

10. 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                    [Page 10]