MMUSIC WG                                               M. Garcia-Martin
Internet-Draft                                                  Ericsson
Intended status: Standards Track                         S. Veikkolainen
Expires: September 2, 2010                                         Nokia
                                                               R. Gilman
                                                           March 1, 2010


   Miscellaneous Capabilities Negotiation in the Session Description
                             Protocol (SDP)
                   draft-ietf-mmusic-sdp-misc-cap-00

Abstract

   SDP has been extended with a capability negotiation mechanism
   framework that allows the endpoints to negotiate transport protocols
   and attributes.  This framework has been extended with a Media
   capabilities negotiation mechanism that allows endpoints to negotiate
   additional media-related capabilities.  This negotiation is embedded
   into the widely-used SDP offer/answer procedures.

   This memo extends the SDP capability negotiation framework to allow
   endpoints to negotiate a number of miscellaneous SDP capabilities.
   In particular, this memo provides a mechanism to negotiate media
   titles ("i=" line for each media), connection data ("c=" line), and
   media bandwidth ("b=" line).

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.




Garcia-Martin, et al.   Expires September 2, 2010               [Page 1]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   This Internet-Draft will expire on September 2, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.























Garcia-Martin, et al.   Expires September 2, 2010               [Page 2]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Extensions to SDP  . . . . . . . . . . . . . . . . . . . .  5
       3.1.1.  Bandwidth Capability . . . . . . . . . . . . . . . . .  6
       3.1.2.  Connection Data Capability . . . . . . . . . . . . . .  8
       3.1.3.  Information Capability . . . . . . . . . . . . . . . . 10
     3.2.  Session Level versus Media Level . . . . . . . . . . . . . 13
   4.  Field Replacement Rules  . . . . . . . . . . . . . . . . . . . 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  New SDP Attributes . . . . . . . . . . . . . . . . . . . . 14
     5.2.  New Option Tags  . . . . . . . . . . . . . . . . . . . . . 14
     5.3.  New SDP Capability Negotiation Configuration Parameters  . 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16






























Garcia-Martin, et al.   Expires September 2, 2010               [Page 3]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


1.  Introduction

   The Session Description Protocol (SDP) [RFC4566] is intended for
   describing multimedia sessions for the purposes of session
   announcement, session invitation, and other forms of multimedia
   session initiation.  SDP has been extended with a capability
   negotiation mechanism framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] that allows the
   endpoints to negotiate capabilities, such as support for Realtime
   Transport Protocol (RTP) [RFC3550] and Secure Realtime Transport
   Protocol (SRTP) [RFC3711].  The SDP media capabilities
   [I-D.ietf-mmusic-sdp-media-capabilities] provides negotiation
   capabilities to media lines as well.

   This negotiation is embedded into the widely used SDP offer/answer
   procedures [RFC3264].  This memo provides the means to negotiate
   further capabilities than those specified in the SDP capability
   negotiation mechanism framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media
   capabilities [I-D.ietf-mmusic-sdp-media-capabilities].  In
   particular, this memo provides a mechanism to negotiate media titles
   ("i="), connection data ("c="), and media bandwidth ("b=").  It would
   have been possible to define a mechanism to negotiate media
   encryption keys ("k=").  However, the usage of the media encryption
   keys ("k=") is highly discouraged in favour of other existing more
   sophisticated mechanisms.  Therefore, we are not providing a
   mechanism to provide capabilities for media encryption keys ("k=") at
   this stage.

   Since the three added capabilities are highly unconnected, it is not
   expected that implementations will support all three at the same
   time.  Instead, it is expected that applications will choose their
   needed capability for their specific purpose.  Due to this, we are
   writing the normative part pertaining to each capability in a self-
   contained section.  In particular, Section 3.1.1 describes the
   bandwidth capability extension, Section 3.1.2 describes the
   connection data capability extension, and Section 3.1.3 describes the
   information capability extension.  Separate option tags are defined
   for each capability.


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 BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.



Garcia-Martin, et al.   Expires September 2, 2010               [Page 4]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


3.  Protocol Description

3.1.  Extensions to SDP

   The SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] and the SDP media
   capabilities [I-D.ietf-mmusic-sdp-media-capabilities] specify
   attributes for negotiating SDP capabilities.  These documents specify
   new attributes (e.g., 'acap', 'tcap', 'mcap') for achieving their
   purpose.  In this document we define a number of new additional
   capability attributes for SDP lines of the the general form:

      type=value

   for types "i", "c", and "b".  The corresponding capability attributes
   are defined as "icap", "ccap", and "bcap", respectively.

   From the sub-rules of "a=" line in SDP [RFC4566], SDP attributes are
   of the form:

   attribute          = (att-field ":" att-value) / att-field
   att-field          = token
   att-value          = byte-string

   Capability attributes use only the 'att-field:att-value' form.

   The new attributes may be referenced in potential configurations
   ("a=pcfg") or in latent configurations ("a=lcfg"), as productions
   conforming to the extension-config-list as defined in
   [I-D.ietf-mmusic-sdp-capability-negotiation].

   extension-config-list = ["+"] ext-cap-name "="
                                  ext-cap-list
   ext-cap-name          = 1*(ALPHA / DIGIT)
   ext-cap-list          = 1*VCHAR  ; defined in [RFC4234]

   The optional "+" is used to indicate that the entire configuration,
   not just the parameter, must be ignored if the parameter is not
   supported.  The attributes may be referenced in actual configurations
   as productions conforming to the sel-extension-config defined in
   [I-D.ietf-mmusic-sdp-capability-negotiation].

   sel-extension-config = ext-cap-name "=" 1*VCHAR

   The specific parameters are defined in the individual description of
   each capability, below.

   It is not the intention of this work to negotiate these new



Garcia-Martin, et al.   Expires September 2, 2010               [Page 5]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   capabilities at the session level, rather only at the media level.
   Therefore, capabilities referenced by any configuration attribute
   MUST appear at the media level when a configuration is "converted" to
   a corresponding media block.  For this reason, the "icap" attribute
   is called the "media information capability".  Specific values for
   each new attribute are described below.

3.1.1.  Bandwidth Capability

   According to RFC 4566 [RFC4566] the bandwidth field denotes the
   proposed bandwidth to be used by the session or media.  For what it
   concerns this memo, we focus on the bandwidth at the media level.
   This bandwidth field is specified in RFC 4566 [RFC4566] according to
   the following syntax:

      b=<bwtype>:<bandwidth>

   where <bwtype> is an alphanumeric modifier giving the meaning of the
   <bandwidth> figure.

   In this document, we define a new capability attribute: the bandwidth
   capability attribute "bcap".  This attribute lists bandwidth as
   capabilities according to the following definition:

      "a=bcap:" bw-cap-num 1*WSP bwtype ":" bandwidth CRLF

   where <bw-cap-num> is a unique ordinal identifier of the bandwidth
   capability, and the other elements are as defined for the "b=" field
   in [RFC4566].

   This format satisfies the general attribute production rules in
   [RFC4566] according to the following Augmented Backus-Naur Form
   (ABNF) [RFC5234] syntax:

   att-field       = "bcap"
   att-value       = bw-cap-num 1*WSP bwtype ":" bandwidth
   bw-cap-num      = 1*DIGIT   ; integer between 1 and 2^31-1, inclusive

   Negotiation of bandwidth per media stream can be useful when
   negotiating media encoding capabilities with different bandwidths.

3.1.1.1.  Configuration Parameters

   The SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the
   existence of the "pcfg" and "acfg" attributes, which can carry one or
   more potential configurations to be negotiated.  The concept is
   extended by the the Media Capabilities Negotiation



Garcia-Martin, et al.   Expires September 2, 2010               [Page 6]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute
   that conveys latent configurations.  Extensions to the "pcfg" and
   "lcfg" attributes are defined through <extension-config-list>, and
   extensions to the "acfg" attribute are defined through the <sel-
   extension-config> as defined in
   [I-D.ietf-mmusic-sdp-capability-negotiation].

   In this document we extend the <extension-config-list> field to be
   able to convey lists of bandwidth capabilities in latent or potential
   configurations, according to the following Augmented Backus-Naur Form
   (ABNF) [RFC5234] syntax:

   extension-config-list  = bandwidth-config-list

   bandwidth-config-list  = ["+"] "b=" bw-cap-list *(BAR b-cap-list)
   bw-cap-list            = bw-cap-num *("," b-cap-num)
   bw-cap-num             = 1*DIGIT   ; 1 to 2^32-1 inclusive

       Figure 1: Syntax of the bandwidth parameter in lcfg and pcfg
                                attributes

   Each bandwidth capability configuration is a comma-separated list of
   bandwidth capability attribute numbers where 'b-cap-num' refers to
   the bw-cap-num bandwidth capability numbers defined explicitly
   earlier in this document, and hence must be between 1 and 2^31-1
   (both included).  Alternative bandwidth configurations are separated
   by a vertical bar ("|").

   The bandwidth parameter to the actual configuration attribute
   ("a=acfg") is formulated as a sel-extension-config with

      ext-cap-name = "b"

   hence

   sel-extension-config = sel-bandwidth-config
   sel-bandwidth-config = "b=" bw-cap-list  ; bw-cap-list as above.

      Figure 2: Syntax of the bandwidth parameter in acfg attributes

3.1.1.2.  Option tag

   The SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for
   capability negotiation extensions to be defined.  Associated with
   each such extension is an option tag that identifies the extension in
   question.  Hereby, we define a new option tag of "bcap-v0" that
   identifies support for the bandwidth capability.  This option tag



Garcia-Martin, et al.   Expires September 2, 2010               [Page 7]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   SHOULD be added to other existing option tags present in the "csup"
   and "creq" attributes in SDP, according to the procedures defined in
   the SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation].

3.1.2.  Connection Data Capability

   According to SDP [RFC4566], the connection data field in SDP contains
   the connection data, and it has the following syntax:

      c=<nettype> <addrtype> <connection-address>

   where <nettype> indicates the network type, <addrtype> indicates the
   address type, and the <connection-address> is the connection address,
   which is dependent on the address type.  For internet (IN) network
   type transport addresses, the port number (<port>) which appears in
   the media line is also required to complete the address.

   The address types "IP4" and "IP6" indicate the type of IP addresses.

   [I-D.ietf-mmusic-sdp-cs] defines a circuit-switched (CS) network type
   intended primarily to identify an alternative media path in case IN
   connectivity is overloadad or unavailable.  This use requires the SDP
   Capability Negotiation ([I-D.ietf-mmusic-sdp-capability-negotiation])
   framework, as illustrated below.

   SDP [RFC4566] permits specification of connection data at the session
   or at the media level.  In order to permit negotiation of connection
   data at the media level, we define the connection data capability
   attribute ("a=ccap") in the form:

      "a=ccap:" conn-cap-num 1*WSP nettype SP addrtype SP connection-
      address SP port ["/" integer] CRLF

   where <conn-cap-num> is a unique ordinal identifier of the connection
   data capability, and the other elements are as defined in [RFC4566].

   This format corresponds to the [RFC4566] attribute production rules
   according to the following Augmented Backus-Naur Form (ABNF)
   [RFC5234] syntax:

   att-field       = "ccap"
   att-value       = conn-cap-num 1*WSP nettype SP addrtype
                     SP connection-address SP port ["/" integer]
   conn-cap-num    = 1*DIGIT   ; integer between 1 and 2^31-1, inclusive

   The ccap attribute contains a port number, which is required for the
   media line when converting a potential or latent configuration into a



Garcia-Martin, et al.   Expires September 2, 2010               [Page 8]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   conventional media description.  The ccap attribute is a media-level-
   only attribute.  When a potential configuration references a ccap
   attribute, and that configuration is converted to an equivalent media
   description, the resulting configuration will contain a media-level
   connection ("c=") line derived from the ccap information.

   A potential or latent configuration may invoke no more than one ccap
   attribute at a time (see below).

   The connection information capability can be used to negotiate the
   use of IPv4 or IPv6 addresses without resort to Interactive
   Connectivity Establishment(ICE) [I-D.ietf-mmusic-ice].  Note,
   however, that ICE provides for real-time reachability testing of
   multiple addresses, whereas use of the connection capability forces
   an early choice of connection address.

   [I-D.boucadair-mmusic-altc] describes a simple method of specifying
   alternative network addresses when the transport protocol (<proto>)
   is the same.

3.1.2.1.  Configuration Parameters

   The SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the
   existence of the "pcfg" and "acfg" attributes, which can carry one or
   more potential configurations to be negotiated.  The concept is
   extended by the the Media Capabilities Negotiation
   [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute
   that conveys latent configurations.

   In this document we define a <connection-config> parameter to be used
   to specify a connection data capability in a potential or latent
   configuration attribute.  The parameter follows the form of an
   extension-config-list, with

      ext-cap-name = "c"

      ext-cap-list = conn-cap-list

   where, according to the following Augmented Backus-Naur Form (ABNF)
   [RFC5234] syntax:

   extension-config-list = conn-config-list
   conn-config-list      = "c=" conn-cap-list
   conn-cap-list         = conn-cap-num *(BAR conn-cap-num)
   conn-cap-num          = 1*DIGIT   ; 1 to 2^32-1 inclusive

    Figure 3: Syntax of the connection data parameter in lcfg and pcfg



Garcia-Martin, et al.   Expires September 2, 2010               [Page 9]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


                                attributes

   Each capability configuration alternative contains a single
   connection data capability attribute number and refers to the conn-
   cap-num capability number defined explicitly earlier in this
   document, and hence must be between 1 and 2^31-1 (both included).
   The connection data capability allows the expression of only a single
   capability in each alternative, rather than a list of capabilities,
   since no more than a single connection data field is permitted per
   media block.  Nevertheless, it is still allowed to express
   alternative potential connection configurations separated by a
   vertical bar ("|").

   The connection data parameter to the actual configuration attribute
   ("a=acfg") is formulated as a sel-extension-config with

      ext-cap-name = "c"

   hence

   sel-extension-config = sel-connection-config
   sel-connection-config = "c=" conn-cap-num  ; as defined above.

   Figure 4: Syntax of the connection data parameter in acfg attributes

3.1.2.2.  Option tag

   The SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] solution allows for
   capability negotiation extensions to be defined.  Associated with
   each such extension is an option tag that identifies the extension in
   question.  Hereby, we define a new option tag of "ccap-v0" that
   identifies support for the connection data capability.  This option
   tag SHOULD be added to other existing option tags present in the
   "csup" and "creq" attributes in SDP, according to the procedures
   defined in the SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation].

3.1.3.  Information Capability

   RFC 4566 [RFC4566] provides for the existence of an information field
   expressed in the format of the "i=" line, which can appear either at
   the session level or at the media level.  An "i=" line that is
   present at the session level is known as the "session name", and its
   purpose is to convey a human-readable textual information about the
   session.  We don't see much usage of capabilities related to the "i="
   line at the session level.




Garcia-Martin, et al.   Expires September 2, 2010              [Page 10]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   The "i=" line in SDP can also appear at the media level, in which
   case it is used to provide human-readable information about the media
   stream to which it is related, e.g., it may indicate the purpose of
   the media stream.  The information field is not to be confused with
   the label attribute ("a=label:...), [RFC4574]) which provides a
   machine-readable tag.  It is foreseen that applications declaring
   capabilities related to different configurations of a media stream
   may need to provide different identifying information for each of
   those configurations.  That is, a party might offer alternative media
   configurations for a stream, each of which represents a different
   presentation of the same or similar information.  For example, an
   audio stream might offer English or Spanish configurations, or a
   video stream might offer a choice of video source such as speaker
   camera, group camera, or document viewer.  The information capability
   is needed to inform the answering user in order to select the proper
   choice, and the label is used to inform the offering machine which
   choice the answerer has selected.  Hence, there is value in defining
   a mechanism to provide information of media streams as capabilities.

   According to SDP [RFC4566], the media label has the following syntax:

      "i="text

   where "text" represents a human-readable text indicating the purpose
   of the media stream.

   In this document we define a new capability attribute: the
   information media capability, "icap".  This attribute lists
   information media labels as capabilities, according to the following
   definition:

      "a=icap:" info-cap-num 1*WSP text

   where <info-cap-num> is the ordinal identifier of the particular
   media information capability and <text> is a human-readable text that
   indicates the purpose of the media stream it is supposed to
   characterize.

   As an example, one might use:

      a=icap:1 Document Camera

   to represent a purpose of a media stream identified with the
   capability number 1.

   The media information capability attribute satisfies the general
   attribute production rules in [RFC4566] according to the following
   Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:



Garcia-Martin, et al.   Expires September 2, 2010              [Page 11]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   att-field       = "icap"
   att-value       = info-cap-num 1*WSP text
                               ; text is defined in RFC 4566
   info-cap-num    = 1*DIGIT   ; integer between 1 and 2^31-1

3.1.3.1.  Configuration Parameters

   The SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation] provides for the
   existence of the "pcfg" and "acfg" attributes, which can carry one or
   more potential configurations to be negotiated.  The concept is
   extended by the the Media Capabilities Negotiation
   [I-D.ietf-mmusic-sdp-media-capabilities] with an "lcfg" attribute
   that conveys latent configurations.

   In this document, we define an <info-config-list> parameter to be
   used to convey information capabilities in a potential or latent
   configuration.  This parameter is defined as an <extension-config-
   list> with the following associations:

      ext-cap-name = "i"

      ext-cap-list = info-cap-list

   This leads to the following definition for the information capability
   parameter:

   extension-config-list = info-config-list
   info-config-list      = "i=" info-cap-list
   info-cap-list         = info-cap-num *(BAR info-cap-num)
   info-cap-num          = 1*DIGIT   ; 1 to 2^32-1 inclusive
                            ; BAR defined in SDP capabilities
                            ; negotiation

   Figure 5: Syntax of the information capability parameter in lcfg and
                              pcfg attributes

   Each potential capability configuration contains a single information
   capability attribute number where 'info-cap-num' is the information
   capability number defined explicitly earlier in this document, and
   hence must be between 1 and 2^31-1 (both included).  The information
   capability allows the expression of only a single capability in each
   alternative, since no more than a single information field is
   permitted per media block.  Nevertheless, it is still allowed to
   express alternative potential information configurations separated by
   a vertical bar ("|").





Garcia-Martin, et al.   Expires September 2, 2010              [Page 12]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


3.1.3.2.  Option Tag

   At present, it is difficult to envision a scenario in which the
   'icap' attribute must be supported or the offer must be rejected.  In
   most cases, if the icap attribute or its contents were to be ignored,
   an offered configuration could still be chosen based on other
   criteria such as configuration numbering.  However, one might imagine
   an SDP offer that contained English and Spanish potential
   configurations for an audio stream.  The session might be
   unintelligible if the choice is based on configuration numbering,
   rather than informed user selection.  Based on such considerations,
   it may well prove useful to announce the ability to use the icap
   attribute and its contents to select media configurations, or to
   inform the user about the selected configuration(s).  Therefore, we
   define a new option tag of "icap-v0" that identifies support for the
   media information capability.  This option tag SHOULD be added to
   other existing option tags present in the "csup" and/or "creq"
   attributes in SDP, according to the procedures defined in the SDP
   Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation].  The discusion above
   suggests that "icap-v0" will typically appear in a "csup" attribute,
   but rarely in a "creq" attribute.

3.2.  Session Level versus Media Level

   The icap, ccap, and bcap attributes can appear at the session level
   and/or at the media level, but MUST be interpreted as a media-level
   capability.  To avoid confusion, the <type-attr-num> for each line
   must be unique across all capability attributes of the same type
   within the entire session description.  As described below, these
   capability attributes may be referenced by acfg, pcfg and/or lcfg
   attributes.


4.  Field Replacement Rules

   To simplify the construction of SDP records, given the need to
   include fields at the base level for endpoints that do not support
   capabilities negotiation, we define some simple field-replacement
   rules for those fields invoked by potential or latent configurations.
   In particular, any i-field or c-field invoked by a configuration MUST
   replace the corresponding field, if present at the base media level.
   Any b-field invoked by a configuration MUST replace any b-field of
   the same bandwidth type at the media level.







Garcia-Martin, et al.   Expires September 2, 2010              [Page 13]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


5.  IANA Considerations

5.1.  New SDP Attributes

   IANA is hereby requested to register the following new SDP
   attributes:

      Attribute name: icap

      Long form name: Information Capability

      Type of attribute: Media-level

      Subject to charset: Yes

      Purpose: Negotiate human-readable media information

      Appropriate values: See Section 3.1.3

      Attribute name: ccap

      Long form name: Connection Data Capability

      Type of attribute: Media-level

      Subject to charset: No

      Purpose: Negotiate media-level connection data

      Appropriate values: See Section 3.1.2

      Attribute name: bcap

      Long form name: Bandwidth Capability

      Type of attribute: Media-level

      Subject to charset: No

      Purpose: Negotiate media-level bandwidths

      Appropriate values: See Section 3.1.1

5.2.  New Option Tags

   IANA is hereby requested to add the new option tags "ccap-v0",
   "icap-v0", and "bcap-v0", defined herein, to the SDP Capability
   Negotiation Option Tag Registry.



Garcia-Martin, et al.   Expires September 2, 2010              [Page 14]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


5.3.  New SDP Capability Negotiation Configuration Parameters


6.  Security Considerations

   This document provides an extension on top of RFC 4566 [RFC4566], RFC
   3264 [RFC3264], SDP Capability Negotiation Framework
   [I-D.ietf-mmusic-sdp-capability-negotiation], and SDP Media
   Capabilities Negotiation [I-D.ietf-mmusic-sdp-media-capabilities].
   As such, the security considerations of those documents apply.


7.  Acknowledgments

   Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson
   for arguing for the existence of this document and early reviewing
   it.


8.  References

8.1.  Normative References

   [I-D.boucadair-mmusic-altc]
              Boucadair, M., Kaplan, H., Gilman, R., and S.
              Veikkolainen, "Session Description Protocol (SDP)
              Alternate Connectivity (ALTC) Attribute",
              draft-boucadair-mmusic-altc-00 (work in progress),
              February 2010.

   [I-D.ietf-mmusic-sdp-capability-negotiation]
              Andreasen, F., "SDP Capability Negotiation",
              draft-ietf-mmusic-sdp-capability-negotiation-11 (work in
              progress), February 2010.

   [I-D.ietf-mmusic-sdp-cs]
              Garcia, M. and S. Veikkolainen, "Session Description
              Protocol (SDP) Extension For Setting Up Audio and Video
              Media Streams Over Circuit-Switched Bearers In The Public
              Switched Telephone Network (PSTN)",
              draft-ietf-mmusic-sdp-cs-03 (work in progress),
              February 2010.

   [I-D.ietf-mmusic-sdp-media-capabilities]
              Gilman, R., Even, R., and F. Andreasen, "SDP media
              capabilities Negotiation",
              draft-ietf-mmusic-sdp-media-capabilities-09 (work in
              progress), February 2010.



Garcia-Martin, et al.   Expires September 2, 2010              [Page 15]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


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

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

8.2.  Informative References

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4574]  Levin, O. and G. Camarillo, "The Session Description
              Protocol (SDP) Label Attribute", RFC 4574, August 2006.


Authors' Addresses

   Miguel A. Garcia-Martin
   Ericsson
   Calle Via de los Poblados 13
   Madrid,   28033
   Spain

   Phone: +34 91 339 1000
   Email: miguel.a.garcia@ericsson.com








Garcia-Martin, et al.   Expires September 2, 2010              [Page 16]


Internet-Draft      Miscellaneous Capabilities in SDP         March 2010


   Simo Veikkolainen
   Nokia
   P.O. Box 407
   NOKIA GROUP, FI  00045
   Finland

   Phone: +358 50 486 4463
   Email: simo.veikkolainen@nokia.com


   Robert R. Gilman
   3243 W. 11th Ave. Dr.
   Broomfield, Colorado  80020
   U.S.A.

   Phone: +1 303 898 9780
   Email: bob_gilman@comcast.net


































Garcia-Martin, et al.   Expires September 2, 2010              [Page 17]