Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)

The SDP Capability Negotiation Framework and the SDP Media Capabilities Negotiation 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: "bcap": bandwidth capability "ccap": connection data capability "icap": title capability From the sub-rules of the attribute ("a=") line in SDP, 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 and 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. The new capabilities may also be referenced in actual configurations ("a=acfg") as productions conforming to the <sel-extension-config> defined in RFC 5939.

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, each extension capability must specify the implication of making it part of a configuration at the media level. According to SDP, "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 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 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&nbhy;based media capabilities are to be interpreted as media-level attributes).

According to RFC 4566, 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 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. This format satisfies the general attribute production rules in SDP, according to the following Augmented Backus-Naur Form (ABNF) syntax:

att-field =/ "bcap" att-value =/ bw-cap-num 1*WSP bwtype ":" bandwidth bw-cap-num = 1*10(DIGIT) ; DIGIT defined in RFC 5234 Negotiation of bandwidth per media stream can be useful when negotiating media encoding capabilities with different bandwidths.

The SDP Capability Negotiation Framework provides for the existence of the "pcfg" and "acfg" attributes. The concept is extended by the SDP Media Capabilities Negotiation 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. 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) 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 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 either. 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.

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

According to SDP, 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 ), used for describing Asynchronous Transfer Mode (ATM) bearer connections. The Circuit-Switched (CS) descriptions in the SDP document adds a "PSTN" network type for expressing a Public Switched Telephone Network (PSTN) circuit switch. SDP 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&nbhy;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 . This format corresponds to the attribute production rules, according to the following Augmented Backus-Naur Form (ABNF) 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 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&nbhy;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). The "ccap" attribute does not change that; hence, the combined set of actual and potential configurations (as defined in ) 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. 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:

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 The example in represents an SDP offer indicating an audio flow using RTP, such as the one represented in , or an audio flow using a circuit-switched connection, such as the one represented in .

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

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 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", 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)". 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 , require additional specifications.

The SDP Capability Negotiation Framework 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 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) 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 Each capability configuration alternative contains a single connection data capability attribute number and refers to the conn&nbhy;cap&nbhy;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 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.

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

SDP 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:", ), which provides a machine-readable tag. It is foreseen that applications declaring capabilities related to different configurations of a media stream may need to provide different identifying information for each of those configurations. That is, a party might offer alternative media configurations for a stream, each of which represents a different presentation of the same or similar information. For example, an audio stream might offer English or Spanish configurations, or a video stream might offer a choice of video source such as speaker camera, group camera, or document viewer. The 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 , 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/&wj;title information each using different character sets. Instead, the session/&wj;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, 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. 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" and the generic attribute capability attribute ("a=acap:") defined in "Session Description Protocol (SDP) Capability Negotiation").

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, according to the following Augmented Backus-Naur Form (ABNF) 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

The SDP Capability Negotiation Framework provides for the existence of the "pcfg" and "acfg" attributes. The concept is extended by the SDP Media Capabilities Negotiation with an "lcfg" attribute that conveys latent configurations. 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&nbhy;config&nbhy;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 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.

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 . The discussion above suggests that "icap-v0" will typically appear in a "csup" attribute, but rarely in a "creq" attribute.

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

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

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

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

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. 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&nbhy;preference configurations that were not chosen.

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 and in accordance with the procedures defined in Section 3.6.4 of the SDP Capability Negotiation .