Movatterモバイル変換

[RFC Home] [TEXT|PDF|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

PROPOSED STANDARD
Errata Exist

Internet Engineering Task Force (IETF) M. Garcia-MartinRequest for Comments: 7006 EricssonCategory: Standards Track S. VeikkolainenISSN: 2070-1721 Nokia R. Gilman September 2013Miscellaneous Capabilities Negotiation in theSession 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 inSection 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7006.Garcia-Martin, et al. Standards Track [Page 1]

RFC 7006 SDP Misc. Capabilities Negotiation September 2013Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 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 Contents1. Introduction ....................................................32. Conventions Used in This Document ...............................33. Protocol Description ............................................43.1. Extensions to SDP ..........................................43.1.1. Bandwidth Capability ................................63.1.2. Connection Data Capability ..........................83.1.3. Title Capability ...................................123.2. Session Level versus Media Level ..........................163.3. Offer/Answer Model Extensions .............................173.3.1. Generating the Initial Offer .......................173.3.2. Generating the Answer ..............................173.3.3. Offerer Processing of the Answer ...................183.3.4. Modifying the Session ..............................184. Field Replacement Rules ........................................185. Security Considerations ........................................186. IANA Considerations ............................................196.1. New SDP Attributes ........................................196.2. New Option Tags ...........................................206.3. New SDP Capability Negotiation Configuration Parameters ...207. Acknowledgments ................................................208. References .....................................................208.1. Normative References ......................................208.2. Informative References ....................................21Garcia-Martin, et al. Standards Track [Page 2]

RFC 7006           SDP Misc. Capabilities Negotiation     September 20131.  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, andSection 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 inBCP 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 20133.  Protocol Description3.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 inRFC 5939 [RFC5939] andRFC 6871 [RFC6871].      extension-config-list = ["+"] ext-cap-name "=" ext-cap-list      ext-cap-name          = 1*(ALPHA / DIGIT)                              ; ALPHA and DIGIT defined inRFC 5234      ext-cap-list          = 1*VCHAR  ; VCHAR defined inRFC 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 inRFC 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 levelGarcia-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 toRFC 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 inRFC 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 inRFC 5234                 Figure 2: Syntax of the "bcap" attributeGarcia-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 inRFC 5939     bw-cap-list            = bw-cap-num *("," bw-cap-num)     bw-cap-num             = 1*10(DIGIT)   ; DIGIT defined inRFC 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" attributes3.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" (seeRFC 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 inRFC 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 isGarcia-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" attributes3.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 streamGarcia-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 inRFC 4566         title-cap-num   = 1*10(DIGIT)   ; DIGIT defined inRFC 5234                 Figure 11: Syntax of the "icap" attribute3.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 inRFC 5939         title-cap-num         = 1*10(DIGIT) ; DIGIT defined inRFC 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" attributesGarcia-Martin, et al.        Standards Track                   [Page 15]

RFC 7006 SDP Misc. Capabilities Negotiation September 20133.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 inRFC 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 20133.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 inSection 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 20133.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 inSection 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 inSection 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 (seeSection 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 Considerations6.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: SeeRFC 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: SeeRFC 7066, Section 3.1.2 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.comGarcia-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: SeeRFC 7066, Section 3.1.3 Contact name: Miguel A. Garcia Miguel.A.Garcia@ericsson.com6.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. References8.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 2013Authors' 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.netGarcia-Martin, et al.        Standards Track                   [Page 22]

[8]ページ先頭