diff options
Diffstat (limited to 'doc/rfc/rfc7006.txt')
| -rw-r--r-- | doc/rfc/rfc7006.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7006.txt b/doc/rfc/rfc7006.txt new file mode 100644 index 0000000..2a0f38b --- /dev/null +++ b/doc/rfc/rfc7006.txt @@ -0,0 +1,1235 @@ + + + + + + +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] + |