GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7006

Internet Engineering Task Force (IETF) M. Garcia-Martin Request for Comments: 7006 Ericsson Category: Standards Track S. Veikkolainen ISSN: 2070-1721 Nokia

                                                             R. Gilman
                                                        September 2013
           Miscellaneous Capabilities Negotiation in the
                 Session Description Protocol (SDP)

Abstract

 The Session Description Protocol (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 three additional SDP capabilities.  In
 particular, this memo provides a mechanism to negotiate bandwidth
 ("b=" line), connection data ("c=" line), and session or media titles
 ("i=" line for each session or media).

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7006.

Garcia-Martin, et al. Standards Track [Page 1] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

Copyright Notice

 Copyright (c) 2013 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 Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
 2. Conventions Used in This Document ...............................3
 3. Protocol Description ............................................4
    3.1. Extensions to SDP ..........................................4
         3.1.1. Bandwidth Capability ................................6
         3.1.2. Connection Data Capability ..........................8
         3.1.3. Title Capability ...................................12
    3.2. Session Level versus Media Level ..........................16
    3.3. Offer/Answer Model Extensions .............................17
         3.3.1. Generating the Initial Offer .......................17
         3.3.2. Generating the Answer ..............................17
         3.3.3. Offerer Processing of the Answer ...................18
         3.3.4. Modifying the Session ..............................18
 4. Field Replacement Rules ........................................18
 5. Security Considerations ........................................18
 6. IANA Considerations ............................................19
    6.1. New SDP Attributes ........................................19
    6.2. New Option Tags ...........................................20
    6.3. New SDP Capability Negotiation Configuration Parameters ...20
 7. Acknowledgments ................................................20
 8. References .....................................................20
    8.1. Normative References ......................................20
    8.2. Informative References ....................................21

Garcia-Martin, et al. Standards Track [Page 2] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

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 an SDP Capability
 Negotiation Mechanism Framework [RFC5939] that allows the endpoints
 to negotiate capabilities, such as support for the Real-time
 Transport Protocol (RTP) [RFC3550] and the Secure Real-time Transport
 Protocol (SRTP) [RFC3711].  The SDP Media Capabilities Negotiation
 [RFC6871] provides negotiation capabilities to media lines as well.
 The capability negotiation is embedded into the widely used SDP
 offer/answer procedure [RFC3264].  This memo provides the means to
 negotiate further capabilities than those specified in the SDP
 Capability Negotiation Mechanism Framework [RFC5939] and the SDP
 Media Capabilities Negotiation [RFC6871].  In particular, this memo
 provides a mechanism to negotiate bandwidth ("b="), connection data
 ("c="), and session or media titles ("i=").
 Since the three added capabilities are independent, it is not
 expected that implementations will necessarily support all of them at
 the same time.  Instead, it is expected that applications will choose
 their needed capability for their specific purpose.  For this reason,
 the normative part pertaining to each capability is in a self-
 contained section: 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 title capability
 extension.  Separate SDP Capability Negotiation option tags are
 defined for each capability, allowing endpoints to indicate and/or
 require support for these extensions according to procedures defined
 in SDP Capability Negotiation [RFC5939].

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. Standards Track [Page 3] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

3. Protocol Description

3.1. Extensions to SDP

 The SDP Capability Negotiation Framework [RFC5939] and the SDP Media
 Capabilities Negotiation [RFC6871] specify attributes for negotiating
 SDP capabilities.  These documents specify new attributes (e.g.,
 "acap", "tcap", "rmcap", and "omcap") for achieving their purpose.
 In this document, we define three new additional capability
 attributes for SDP lines of the general form:
    type=value
 for types "b", "c", and "i".  The corresponding capability attributes
 are respectively defined as:
 o  "bcap": bandwidth capability
 o  "ccap": connection data capability
 o  "icap": title capability
 From the sub-rules of the attribute ("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 capabilities may be referenced in potential configurations
 ("a=pcfg") or in latent configurations ("a=lcfg") as productions
 conforming to the <extension-config-list>, as respectively defined in
 RFC 5939 [RFC5939] and RFC 6871 [RFC6871].
    extension-config-list = ["+"] ext-cap-name "=" ext-cap-list
    ext-cap-name          = 1*(ALPHA / DIGIT)
                            ; ALPHA and DIGIT defined in RFC 5234
    ext-cap-list          = 1*VCHAR  ; VCHAR defined in RFC 5234
 The optional "+" is used to indicate that the extension is mandatory
 and MUST be supported in order to use that particular configuration.

Garcia-Martin, et al. Standards Track [Page 4] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 The new capabilities may also be referenced in actual configurations
 ("a=acfg") as productions conforming to the <sel-extension-config>
 defined in RFC 5939 [RFC5939].
       sel-extension-config = ext-cap-name "=" 1*VCHAR
 The specific parameters are defined in the individual description of
 each capability below.
 The "bcap", "ccap", and "icap" capability attributes can be provided
 at the SDP session and/or media level.  According to the SDP
 Capability Negotiation [RFC5939], each extension capability must
 specify the implication of making it part of a configuration at the
 media level.
 According to SDP [RFC4566], "b=", "c=", and "i=" lines may appear at
 either session or media level.  In line with this, the "bcap",
 "ccap", and "icap" capability attributes, when declared at session
 level, are to be interpreted as if that attribute was provided with
 that value at the session level.  The "bcap", "ccap", and "icap"
 capability attributes declared at media level are to be interpreted
 as if that capability attribute was declared at the media level.
 For example, extending the example in [RFC6871] with "icap" and
 "bcap" capability attributes, we get the following SDP:
       v=0
       o=- 25678 753849 IN IP4 192.0.2.1
       s=
       c=IN IP4 192.0.2.1
       t=0 0
       a=bcap:1 CT:200
       a=icap:1 Video conference
       m=audio 54320 RTP/AVP 0
       a=rmcap:1 L16/8000/1
       a=rmcap:2 L16/16000/2
       a=pcfg:1 m=1|2 pt=1:99,2:98
       m=video 66544 RTP/AVP 100
       a=rmcap:3 H263-1998/90000
       a=rtpmap:100 H264/90000
       a=pcfg:10 m=3 pt=3:101 b=1 i=1
            Figure 1: Example SDP offer with bcap and icap
                        efined at session level

Garcia-Martin, et al. Standards Track [Page 5] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 The above SDP defines one PCMU audio stream and one H.264 video
 stream.  It also defines two RTP-based media capabilities ("rmcap"
 numbered 1 and 2), using 16-bit linear (L16) audio at 8 kbps and 16
 kbps, respectively, as well as an RTP-based media capability for
 H.263 video ("rmcap" numbered 3).  The RTP-based media capabilities
 all appear at the media level.  The example also contains a single
 bandwidth capability ("bcap") and a single title capability ("icap"),
 both defined at session level.  According to the definition above,
 when the capabilities defined in the "bcap" and "icap" attributes are
 referenced from the potential configuration, in the resulting SDP
 they are to be interpreted as session-level attributes (but the
 RTP-based media capabilities are to be interpreted as media-level
 attributes).

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.  In this memo,
 we specify the bandwidth capability attribute, which can also appear
 at the SDP session and/or media level.  The bandwidth field is
 specified in RFC 4566 [RFC4566] with 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 integer within all the bandwidth
 capabilities in the entire SDP, which is used to number the bandwidth
 capability and can take a value between 1 and 2^31-1 (both included).
 The other elements are as defined for the "b=" field in SDP
 [RFC4566].
 This format satisfies the general attribute production rules in SDP
 [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*10(DIGIT)   ; DIGIT defined in RFC 5234
               Figure 2: Syntax of the "bcap" attribute

Garcia-Martin, et al. Standards Track [Page 6] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 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 [RFC5939] provides for the
 existence of the "pcfg" and "acfg" attributes.  The concept is
 extended by the SDP Media Capabilities Negotiation [RFC6871] 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 the SDP
 Capability Negotiation [RFC5939].
 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 bw-cap-list)
                               ; BAR defined in RFC 5939
   bw-cap-list            = bw-cap-num *("," bw-cap-num)
   bw-cap-num             = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
              Figure 3: 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 <bw-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 above syntax is very flexible, allowing referencing to multiple
 "b=" lines per configuration, even for the same <bwtype>.  While the
 need for such definitions is not seen, we have not restricted this,
 as it is not restricted in SDP [RFC4566] either.

Garcia-Martin, et al. Standards Track [Page 7] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 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 4: Syntax of the bandwidth parameter in "acfg" attributes

3.1.1.2. Option Tag

 The SDP Capability Negotiation Framework [RFC5939] 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 "bcap-v0" that
 identifies support for the bandwidth capability.  The endpoints using
 the "bcap" capability attribute SHOULD add the option tag 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 [RFC5939].

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.
 At the moment, network types already defined include "IN", which
 indicates Internet network type, and "ATM" (see RFC 3108 [RFC3108]),
 used for describing Asynchronous Transfer Mode (ATM) bearer
 connections.  The Circuit-Switched (CS) descriptions in the SDP
 document [SDP-CS] adds a "PSTN" network type for expressing a Public
 Switched Telephone Network (PSTN) circuit switch.

Garcia-Martin, et al. Standards Track [Page 8] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 SDP [RFC4566] permits specification of connection data at the SDP
 session and/or 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 CRLF
 where <conn-cap-num> is a unique integer within all the connection
 capabilities in the entire SDP, which is used to identify the
 connection data capability and can take a value between 1 and 2^31-1
 (both included).  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
       conn-cap-num    = 1*10(DIGIT)   ; 1 to 2^31-1, inclusive
                                       ; DIGIT defined in RFC 5234
               Figure 5: Syntax of the "ccap" attribute
 The "ccap" capability attribute allows for expressing alternative
 connections address ("c=") lines in SDP as part of the SDP Capability
 Negotiation process.  One of the primary use cases for this is
 offering alternative connection addresses where the <nettype> is "IN"
 or "PSTN", i.e., selecting between an IP-based bearer or a
 circuit-switched bearer.
 By supporting the "IN" <nettype>, the "ccap" attribute enables the
 signaling of multiple IPv4 and IPv6 addresses; however, the Standards
 Track mechanism for negotiation of alternative IP addresses in SDP is
 Interactive Connectivity Establishment (ICE) [RFC5245].  The "ccap"
 attribute does not change that; hence, the combined set of actual and
 potential configurations (as defined in [RFC5939]) for any given
 media description MUST NOT use the "ccap" attribute to negotiate more
 than one address with an IN network type (i.e., it is not permissible
 to select between "IPv4" and "IPv6" address families or different IP
 addresses within the same IP address family.
 Figure 6 is an example of an SDP offer that includes a "ccap"
 capability attribute.  An audio stream can be set up with an RTP flow
 or by establishing a circuit-switched audio stream:

Garcia-Martin, et al. Standards Track [Page 9] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

           v=0
           o=2987933123 2987933123 IN IP4 198.51.100.7
           s=-
           t=0 0
           a=creq:med-v0,ccap-v0
           m=audio 38902 RTP/AVP 0 8
           c=IN IP4 198.51.100.7
           a=ccap:1 PSTN E164 +15555556666
           a=tcap:2 PSTN
           a=omcap:1 -
           a=acap:1 setup:actpass
           a=acap:2 connection:new
           a=acap:3 cs-correlation:callerid:+15555556666
           a=pcfg:1 c=1 t=2 m=1 a=1,2,3
          Figure 6: Example SDP offer with a "ccap" attribute
 The example in Figure 6 represents an SDP offer indicating an audio
 flow using RTP, such as the one represented in Figure 7, or an audio
 flow using a circuit-switched connection, such as the one represented
 in Figure 8.
           v=0
           o=2987933123 2987933123 IN IP4 198.51.100.7
           s=-
           t=0 0
           m=audio 38902 RTP/AVP 0 8
           c=IN IP4 198.51.100.7
           Figure 7: Equivalent SDP offer with the RTP flow
           v=0
           o=2987933123 2987933123 IN IP4 198.51.100.7
           s=-
           t=0 0
           m=audio 9 PSTN -
           c=PSTN E164 +15555556666
           a=setup:actpass
           a=connection:new
           a=cs-correlation:callerid:+15555556666
     Figure 8: Equivalent SDP offer with the circuit-switched flow
 This document does not define any mechanism for negotiating or
 describing different port numbers; hence, the port number from the
 "m=" line MUST be used by default.  Exceptions to this default can be
 provided by extension mechanisms or network type specific rules.
 This document defines an exception when the network type is "PSTN",

Garcia-Martin, et al. Standards Track [Page 10] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 in which case the port number is replaced with 9 (the "discard"
 port), as described in "Session Description Protocol (SDP) Extension
 for Setting Audio and Video Media Streams over Circuit-Switched
 Bearers in the Public Switched Telephone Network (PSTN)" [SDP-CS].
 An endpoint offering alternative IP and PSTN bearers MUST include the
 IP media description in the actual configuration (IP address in the
 "c=" line and port number in the "m=" line) and the PSTN media
 description in the potential configuration.
 Exceptions for other network types, such as for the "ATM" network
 type defined in [RFC3108], require additional specifications.

3.1.2.1. Configuration Parameters

 The SDP Capability Negotiation Framework [RFC5939] provides for the
 existence of the "pcfg" and "acfg" attributes, which can convey one
 or more configurations to be negotiated.  The concept is extended by
 the SDP Media Capabilities Negotiation [RFC6871] 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*10(DIGIT)   ; 1 to 2^32-1 inclusive
                Figure 9: Syntax of the connection data
               parameter in "lcfg" and "pcfg" 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; hence, the values 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

Garcia-Martin, et al. Standards Track [Page 11] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 permitted per media block.  Nevertheless, it is still allowed to
 express alternative potential connection configurations separated by
 a vertical bar ("|").
 An endpoint includes a plus sign ("+") in the configuration attribute
 to mandate support for this extension.  An endpoint that receives
 this parameter prefixed with a plus sign and does not support this
 extension MUST treat that potential configuration as not valid.
 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 10: Syntax of the connection data parameter
                         in "acfg" attributes

3.1.2.2. Option Tag

 The SDP Capability Negotiation Framework [RFC5939] 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 [RFC5939].

3.1.3. Title Capability

 SDP [RFC4566] provides for the existence of an information field
 expressed in the format of the "i=" line, which can appear at the SDP
 session and/or media level.  An "i=" line that is present at the
 session level is known as the "session name", and its purpose is to
 convey human-readable textual information about the session.
 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; for example, it may indicate the
 purpose of the media stream.  The "i=" line 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

Garcia-Martin, et al. Standards Track [Page 12] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 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 title 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 titles of media streams as capabilities.
 As defined in SDP [RFC4566], the session information field ("i=",
 referred to as "title" in this document) is subject to the
 "a=charset" attribute in order to support different character sets
 and hence internationalization.  The title capability attribute
 itself ("a=icap") is, however, not subject to the "a=charset"
 attribute as this would preclude the inclusion of alternative
 session/title information each using different character sets.
 Instead, the session/title value embedded in an "a=icap" attribute
 (title capability) will be subject to the "a=charset" value used
 within a configuration that includes that title capability.  This
 provides for consistent SDP operation while allowing for capabilities
 and configurations with different session/title information values
 with different character set encodings (with each such configuration
 including an "a=charset" value with the relevant character set for
 the session/title information in question).
 According to SDP [RFC4566], the session information ("i=") line has
 the following syntax:
    "i=" text
 where "text" represents a human-readable text indicating the purpose
 of the session or media stream.
 In this document, we define a new capability attribute: the title
 capability "icap".  This attribute lists session or media titles as
 capabilities, according to the following definition:
    "a=icap:" title-cap-num 1*WSP text
 where <title-cap-num> is a unique integer within all the connection
 capabilities in the entire SDP, which is used to identify the
 particular title capability and can take a value between 1 and 2^31-1
 (both included). <text> is a human-readable text that indicates the
 purpose of the session or media stream it is supposed to
 characterize.

Garcia-Martin, et al. Standards Track [Page 13] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 As an example, one might use:
    a=icap:1 Document Camera
 to define a title capability number 1 to identify a particular source
 of a media stream.
 Or, in another example, one might offer two title capabilities with
 different character encodings (using the charset attribute defined in
 "SDP: Session Description Protocol" [RFC4566] and the generic
 attribute capability attribute ("a=acap:") defined in "Session
 Description Protocol (SDP) Capability Negotiation" [RFC5939]).
             a=icap:1 [Text encoded in ISO-8859-1]
             a=acap:1 charset:ISO-8859-1
             a=icap:2 [Text encoded in UTF-8]
             a=acap:2 charset:UTF-8
 NOTE: Due to limitations of the ASCII encoding of RFCs, the actual
 text with non-printable characters cannot be represented in the text.
 See the PDF format of this RFC for a figure with non-printable
 characters.
 The title capability attribute satisfies the general attribute
 production rules in SDP [RFC4566], according to the following
 Augmented Backus-Naur Form (ABNF) [RFC5234] syntax:
       att-field       =/ "icap"
       att-value       =/ title-cap-num 1*WSP text
                                   ; text defined in RFC 4566
       title-cap-num   = 1*10(DIGIT)   ; DIGIT defined in RFC 5234
               Figure 11: Syntax of the "icap" attribute

3.1.3.1. Configuration Parameters

 The SDP Capability Negotiation Framework [RFC5939] provides for the
 existence of the "pcfg" and "acfg" attributes.  The concept is
 extended by the SDP Media Capabilities Negotiation [RFC6871] with an
 "lcfg" attribute that conveys latent configurations.

Garcia-Martin, et al. Standards Track [Page 14] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 In this document, we define a <title-config-list> parameter to be
 used to convey title 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 = title-cap-list
 This leads to the following definition for the title capability
 parameter:
       extension-config-list =/ title-config-list
       title-config-list     = ["+"] "i=" title-cap-list
       title-cap-list        = title-cap-num *(BAR title-cap-num)
                                       ; BAR defined in RFC 5939
       title-cap-num         = 1*10(DIGIT) ; DIGIT defined in RFC 5234
          Figure 12: Syntax of the title capability parameter
                    in "lcfg" and "pcfg" attributes
 Each potential capability configuration contains a single title
 capability attribute number where "title-cap-num" is the title
 capability number defined explicitly earlier in this document, and
 hence must be between 1 and 2^31-1 (both included).  The title
 capability allows the expression of only a single capability in each
 alternative, since no more than a single-title field is permitted per
 block.  Nevertheless, it is still allowed to express alternative
 potential title configurations separated by a vertical bar ("|").
 An endpoint includes a plus sign ("+") in the configuration attribute
 to mandate support for this extension.  An endpoint that receives
 this parameter prefixed with a plus sign and does not support this
 extension MUST treat that potential configuration as not valid.
 The title parameter to the actual configuration attribute ("a=acfg")
 is formulated as a <sel-extension-config> with
    ext-cap-name = "i"
 hence
       sel-extension-config =/ sel-title-config
       sel-title-config = "i=" title-cap-num  ; as defined above.
     Figure 13: Syntax of the title parameter in "acfg" attributes

Garcia-Martin, et al. Standards Track [Page 15] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

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
 title 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 [RFC5939].  The discussion 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 "bcap", "ccap", and "icap" attributes can appear at the SDP
 session and/or media level.  Endpoints MUST interpret capabilities
 declared at session level as part of the session level in the
 resulting SDP for that particular configuration.  Endpoints MUST
 interpret capabilities declared at media description as part of the
 media level in the resulting SDP for that particular configuration.
 The presence of the "bcap" capability for the same <bwtype> at both
 the session and media level is subject to the same constraints and
 restrictions specified in RFC 4566 [RFC4566] for the bandwidth
 attribute "b=".
 To avoid confusion, the <type-attr-num> for each "a=bcap", "a=ccap",
 and "a=icap" line MUST be unique across all capability attributes of
 the same type within the entire session description.

Garcia-Martin, et al. Standards Track [Page 16] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

3.3. Offer/Answer Model Extensions

 In this section, we define extensions to the offer/answer model
 defined in SDP Offer/Answer Model [RFC3264] and extended in the SDP
 Capability Negotiation [RFC5939] to allow for bandwidth, connection,
 and title capabilities to be used with the SDP Capability Negotiation
 Framework.

3.3.1. Generating the Initial Offer

 When an endpoint generates an initial offer and wants to use the
 functionality described in the current document, it first defines
 appropriate values for the bandwidth, connection data, and/or title
 capability attributes according to the rules defined in [RFC4566] for
 "b=", "c=", and "i=" lines.  The endpoint then MUST include the
 respective capability attributes and associated values in the SDP
 offer.  The preferred configurations for each media stream are
 identified following the media line in a "pcfg" attribute.  Bandwidth
 and title capabilities may also be referenced in latent
 configurations in an "lcfg" attribute, as defined in the SDP Media
 Capabilities Negotiation [RFC6871].
 Implementations are advised to pay attention to the port number that
 is used in the "m=" line.  By default, a potential configuration that
 includes a connection data capability will use the port number from
 the "m=" line, unless the network type is "PSTN", in which case the
 default port number used will be 9.
 The offer SHOULD include the level of capability negotiation
 extensions needed to support this functionality in a "creq"
 attribute.

3.3.2. Generating the Answer

 When the answering party receives the offer, and if it supports the
 required capability negotiation extensions, it SHOULD select the most
 preferred configuration it can support for each media stream and
 build the answer accordingly, as defined in Section 3.6.2 of the SDP
 Capability Negotiation [RFC5939].
 If the connection data capability is used in a selected potential
 configuration chosen by the answerer, that offer configuration MUST
 by default use the port number from the actual offer configuration
 (i.e., the "m=" line), unless the network type is "PSTN", in which
 case the default port MUST be assumed to be 9.  Extensions may be
 defined to negotiate the port number explicitly instead.

Garcia-Martin, et al. Standards Track [Page 17] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

3.3.3. Offerer Processing of the Answer

 When the offerer receives the answer, it MUST process the media lines
 according to normal SDP processing rules to identify the media
 stream(s) accepted by the answer, if any, as defined in Section 3.6.3
 of the SDP Capability Negotiation [RFC5939].  The "acfg" attribute,
 if present, MUST be used to verify the proposed configuration used to
 form the answer and to infer the lack of acceptability of
 higher-preference configurations that were not chosen.

3.3.4. Modifying the Session

 If, at a later time, one of the parties wishes to modify the
 operating parameters of a session, e.g., by adding a new media stream
 or by changing the properties used on an existing stream, it may do
 so via the mechanisms defined for SDP offer/answer [RFC3264] and in
 accordance with the procedures defined in Section 3.6.4 of the SDP
 Capability Negotiation [RFC5939].

4. Field Replacement Rules

 To simplify the construction of SDP records, given the need to
 include fields within the media description in question 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=" or "c=" lines invoked
 by a configuration MUST replace the corresponding line, if present
 within the media description in question.  Any "b=" line invoked by a
 configuration MUST replace any "b=" of the same bandwidth type at the
 media level, but not at the session level.

5. Security Considerations

 This document provides an extension on top of the SDP [RFC4566], SDP
 Offer/Answer Model [RFC3264], SDP Capability Negotiation Framework
 [RFC5939], and SDP Media Capabilities Negotiation [RFC6871].  As
 such, the security considerations of those documents apply.
 The bandwidth capability attribute may be used for reserving
 resources at endpoints and intermediaries that inspect SDP.
 Modification of the bandwidth value by an attacker can lead to the
 network being underutilized (too high bandwidth value) or congested
 (too low bandwidth value).

Garcia-Martin, et al. Standards Track [Page 18] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 Similarly, by modifying the alternative connection address(es), an
 attacker would be able to direct media streams to a desired endpoint,
 thus launching a version of the well-known voice hammer attack (see
 Section 18.5.1 of [RFC5245]).
 The title capability provides for alternative "i=" line information,
 which is intended for human consumption.  However, manipulating the
 textual information could be misused to provide false information,
 leading to a bad user experience or the person using the service
 making a wrong choice regarding the available media streams.
 In case it is essential to protect the capability attribute values,
 one of the security mechanisms proposed in [RFC5939] SHOULD be used.
 The "i=" line, and thus the value carried in the title capability
 attribute, is intended for human-readable description only.  It
 should not be parsed programmatically.

6. IANA Considerations

6.1. New SDP Attributes

 IANA has registered new attributes in the "att-field (both session
 and media level)" subregistry of the "Session Description Protocol
 (SDP) Parameters" registry, according to the following registration
 form:
    Attribute name:      bcap
    Long form name:      Bandwidth Capability
    Type of attribute:   Both media and session level
    Subject to charset:  No
    Purpose:             Negotiate session or media-level bandwidths
    Appropriate values:  See RFC 7066, Section 3.1.1
    Contact name:        Miguel A. Garcia
                         Miguel.A.Garcia@ericsson.com
    Attribute name:      ccap
    Long form name:      Connection Data Capability
    Type of attribute:   Both media and session level
    Subject to charset:  No
    Purpose:             Negotiate media-level connection data
    Appropriate values:  See RFC 7066, Section 3.1.2
    Contact name:        Miguel A. Garcia
                         Miguel.A.Garcia@ericsson.com

Garcia-Martin, et al. Standards Track [Page 19] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

    Attribute name:      icap
    Long form name:      Title Capability
    Type of attribute:   Both media and session level
    Subject to charset:  Yes
    Purpose:             Negotiate human-readable information
                         describing the session or media
    Appropriate values:  See RFC 7066, Section 3.1.3
    Contact name:        Miguel A. Garcia
                         Miguel.A.Garcia@ericsson.com

6.2. New Option Tags

 IANA has added the new option tags "bcap-v0", "ccap-v0", and "icap-
 v0", defined herein, to the "SDP Capability Negotiation Option Tag"
 subregistry of the "Session Description Protocol (SDP) Parameters"
 registry.

6.3. New SDP Capability Negotiation Configuration Parameters

 IANA has added the new parameter identifiers "b" for "Bandwidth", "c"
 for "Connection Data", and "i" for "Title" to the "SDP Capability
 Negotiation Configuration Parameters" subregistry of the "Session
 Description Protocol (SDP) Parameters" registry.  These parameters
 are permitted in "lcfg", "acfg", and "pcfg" attributes.

7. Acknowledgments

 Thanks to Christer Holmberg, Alf Heidermark, and Ingemar Johansson
 for arguing for the existence of this document and reviewing it in
 the early stages.  Thanks to Flemming Andreasen, Andrew Allen, and
 Jonathan Lennox for a detailed review and many suggestions for
 improvement.

8. References

8.1. Normative References

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

Garcia-Martin, et al. Standards Track [Page 20] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

 [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234, January 2008.
 [RFC5939]  Andreasen, F., "Session Description Protocol (SDP)
            Capability Negotiation", RFC 5939, September 2010.
 [RFC6871]  Gilman, R., Even, R., and F. Andreasen, "Session
            Description Protocol (SDP) Media Capabilities
            Negotiation", RFC 6871, February 2013.

8.2. Informative References

 [RFC3108]  Kumar, R. and M. Mostafa, "Conventions for the use of the
            Session Description Protocol (SDP) for ATM Bearer
            Connections", RFC 3108, May 2001.
 [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.
 [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
            (ICE): A Protocol for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", RFC 5245, April
            2010.
 [SDP-CS]   Garcia, M. and S. Veikkolainen, "Session Description
            Protocol (SDP) Extension for Setting Audio and Video Media
            Streams over Circuit-Switched Bearers in the Public
            Switched Telephone Network (PSTN)", Work in Progress, June
            2013.

Garcia-Martin, et al. Standards Track [Page 21] RFC 7006 SDP Misc. Capabilities Negotiation September 2013

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
 Simo Veikkolainen
 Nokia
 P.O. Box 226
 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. Standards Track [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7006.txt · Last modified: 2013/09/24 22:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki