RFC3264] and RFC 5939 [RFC5939] to allow for media format and associated parameter capabilities, latent configurations, and acceptable combinations of media stream configurations to be used with the SDP capability negotiation framework. Note that the procedures defined in this section extend the offer/answer procedures defined in RFC 5939 [RFC5939] Section 6; those procedures form a baseline set of capability negotiation offer/answer procedures that MUST be followed, subject to the extensions defined here. SDP capability negotiation [RFC5939] provides a relatively compact means to offer the equivalent of an ordered list of alternative configurations for offered media streams (as would be described by separate "m=" lines and associated attributes). The attributes "acap", "mscap", "mfcap", "omcap", and "rmcap" are designed to map somewhat straightforwardly into equivalent "m=" lines and conventional attributes when invoked by a "pcfg", "lcfg", or "acfg" attribute with appropriate parameters. The "a=pcfg:" lines, along with the "m=" line itself, represent offered media configurations. The "a=lcfg:" lines represent alternative capabilities for future use.
to be used if the other party does not understand capability negotiations (by default, this is the least preferred configuration). Typically, the media line configuration will contain the minimum acceptable configuration from the offerer's point of view. Preferred configurations for each media stream are identified following the media line. The present offer may also include latent configuration ("lcfg") attributes, at the media level, describing media streams and/or configurations the offerer is not now offering but that it is willing to support in a future offer/answer exchange. A simple example might be the inclusion of a latent video configuration in an offer for an audio stream. Lastly, if the offerer wishes to impose restrictions on the combinations of potential configurations to be used, it will include session capability ("sescap") attributes indicating those. If the offerer requires the answerer to understand the media capability extensions, the offerer MUST include a "creq" attribute containing the value "med-v0". If media capability negotiation is required only for specific media descriptions, the "med-v0" value MUST be provided only in "creq" attributes within those media descriptions, as described in RFC 5939 [RFC5939]. Below, we provide a more detailed description of how to construct the offer SDP. Section 3.3.1. For each non-RTP-based media format the offer wants to include as a media format capability, the offer MUST include an "omcap" attribute for the media format as defined in Section 3.3.1. Since the media capability number space is shared between the "rmcap" and "omcap" attributes, each media capability number provided (including ranges) MUST be unique in the entire SDP. If an "fmtp" parameter value is needed for a media format (whether or not it is RTP based) in a media capability, then the offer MUST include one or more "mfcap" parameters with the relevant "fmtp" parameter values for that media format as defined in Section 3.3.2. When multiple "mfcap" parameters are provided for a given media capability, they MUST be provided in accordance with the concatenation rules in Section 18.104.22.168.
For each of the media format capabilities above, the offer MAY include one or more "mscap" parameters with attributes needed for those specific media formats as defined in Section 3.3.3. Such attributes will be instantiated at the media level; hence, session- level-only attributes MUST NOT be used in the "mscap" parameter. The "mscap" parameter MUST NOT include an "rtpmap" or "fmtp" attribute ("rmcap" and "mfcap" are used instead). If the offerer wants to limit the relevance (and use) of a media format capability or parameter to a particular media stream, the media format capability or parameter MUST be provided within the corresponding media description. Otherwise, the media format capabilities and parameters MUST be provided at the session level. Note, however, that the attribute or parameter embedded in these will always be instantiated at the media level. This is due to those parameters being effectively media-level parameters. If session-level attributes are needed, the "acap" attribute defined in RFC 5939 [RFC5939] can be used; however, it does not provide for media-format-specific instantiation. Inclusion of the above does not constitute an offer to use the capabilities; a potential configuration is needed for that. If the offerer wants to offer one or more of the media capabilities above, they MUST be included as part of a potential configuration ("pcfg") attribute as defined in Section 3.3.4. Each potential configuration MUST include a config-number, and each config-number MUST be unique in the entire SDP (note that this differs from RFC 5939 [RFC5939], which only requires uniqueness within a media description). Also, the config-number MUST NOT overlap with any config-number used by a latent configuration in the SDP. As described in RFC 5939 [RFC5939], lower config-numbers indicate a higher preference; the ordering still applies within a given media description only though. For a media capability to be included in a potential configuration, there MUST be an "m=" parameter in the "pcfg" attribute referencing the media capability number in question. When one or more media capabilities are included in an offered potential configuration ("pcfg"), they completely replace the list of media formats offered in the actual configuration ("m=" line). Any attributes included for those formats remain in the SDP though (e.g., "rtpmap", "fmtp", etc.). For non-RTP-based media formats, the format-name (from the "omcap" media capability) is simply added to the "m=" line as a media format (e.g., t38). For RTP-based media, payload type mappings MUST be provided by use of the "pt" parameter in the potential configuration (see Section 22.214.171.124); payload type escaping may be used in "mfcap", "mscap", and "acap" attributes as defined in Section 3.3.7.
Note that the "mt" parameter MUST NOT be used with the "pcfg" attribute (since it is defined for the "lcfg" attribute only); the media type in a potential configuration cannot be changed from that of the encompassing media description. Section 3.3.6. Each "lcfg" attribute o MUST be specified at the media level o MUST include a config-number that is unique in the entire SDP (including for any potential configuration attributes). Note that config-numbers in latent configurations do not indicate any preference order o MUST include a media type ("mt") o MUST reference a valid transport capability ("t") Each "lcfg" attribute MAY include additional capability references, which may refer to capabilities anywhere in the session description, subject to any restrictions normally associated with such capabilities. For example, a media-level attribute capability must be present at the media level in some media description in the SDP. Note that this differs from the potential configuration attribute, which cannot validly refer to media-level capabilities in another media description (per RFC 5939 [RFC5939], Section 3.5.1). Potential configurations constitute an actual offer and may instantiate a referenced capability. Latent configurations are not actual offers; hence, they cannot instantiate a referenced capability. Therefore, it is safe for those to refer to capabilities in another media description. Section 3.3.8. Each "sescap" attribute MUST include a session-num that is unique in the
entire SDP; the lower the session-num the more preferred that combination is. Furthermore, "sescap" preference order takes precedence over any order specified in individual "pcfg" attributes. For example, if we have pcfg-1 and pcfg-2, and sescap-1 references pcfg-2, whereas sescap-2 references pcfg-1, then pcfg-2 will be the most preferred potential configuration. Without the sescap, pcfg-1 would be the most preferred. RFC5939]. The SDP MAY contain o Media format capabilities and associated parameters ("rmcap", "omcap", "mfcap", and "mscap" attributes) o Potential configurations using those media format capabilities and associated parameters o Latent media streams ("lcfg" attribute) o Acceptable combinations of media stream configurations ("sescap" attribute) The high-level informative description of the operation is as follows: When the answering party receives the offer, if it supports the required capability negotiation extensions, it should select the most-preferred configuration it can support for each media stream, and build its answer accordingly. The configuration selected for each accepted media stream is placed into the answer as a media line with associated parameters and attributes. If a proposed configuration is chosen for a given media stream, the answer must contain an actual configuration ("acfg") attribute for that media stream to indicate which offered "pcfg" attribute was used to build the answer. The answer should also include any potential or latent configurations the answerer can support, especially any configurations compatible with other potential or latent configurations received in the offer. The answerer should make note of those configurations it might wish to offer in the future.
Below we provide a more detailed normative description of how the answerer processes the offer SDP and generates an answer SDP. RFC5939]. 2. It contains a config-number that is unique in the entire SDP and does not overlap with any latent configuration config-numbers. 3. All media format capabilities ("rmcap" or "omcap"), media format parameter capabilities ("mfcap"), and media-specific capabilities ("mscap") referenced by the potential configuration ("m" parameter) are valid themselves (as defined in Sections 3.3.1, 3.3.2, and 3.3.3) and each of them is provided either at the session level or within this particular media description. 4. All RTP-based media format capabilities ("rmcap") have a corresponding payload type ("pt") parameter in the potential configuration that results in mapping to a valid payload type that is unique within the resulting SDP. 5. Any concatenation (see Section 126.96.36.199) and substitution (see Section 3.3.7) applied to any capability ("mfcap", "mscap", or "acap") referenced by this potential configuration results in a valid SDP. Note that since SDP does not interpret the value of "fmtp" parameters, any resulting "fmtp" parameter value will be considered valid. Secondly, the answerer MUST determine the order in which potential configurations are to be negotiated. In the absence of any session capability ("sescap") attributes, this simply follows the rules of RFC 5939 [RFC5939], with a lower config-number within a media description being preferred over a higher one. If a valid "sescap" attribute is present, the preference order provided in the "sescap" attribute MUST take precedence. A "sescap" attribute is considered valid if
1. It adheres to the rules provided in Section 3.3.8. 2. All the configurations referenced by the "sescap" attribute are valid themselves (note that this can include the actual, potential, and latent configurations). The answerer MUST now process the offer for each media stream based on the most preferred valid potential configuration in accordance with the procedures specified in RFC 5939 [RFC5939], Section 3.6.2, and further extended below: o If one or more media format capabilities are included in the potential configuration, then they replace all media formats provided in the "m=" line for that media description. For non- RTP-based media formats ("omcap"), the format-name is added. For RTP-based media formats ("rmcap"), the payload-type specified in the payload-type mapping ("pt") is added and a corresponding "rtpmap" attribute is added to the media description. o If one or more media format parameter capabilities are included in the potential configuration, then the corresponding "fmtp" attributes are added to the media description. Note that this inclusion is done indirectly via the media format capability. o If one or more media-specific capabilities are included in the potential configuration, then the corresponding attributes are added to the media description. Note that this inclusion is done indirectly via the media format capability. o When checking to see if the answerer supports a given potential configuration that includes one or more media format capabilities, the answerer MUST support at least one of the media formats offered. If he does not, the answerer MUST proceed to the next potential configuration based on the preference order that applies. o If session capability ("sescap") preference ordering is included, then the potential configuration selection process MUST adhere to the ordering provided. Note that this may involve coordinated selection of potential configurations between media descriptions. The answerer MUST accept one of the offered sescap combinations (i.e., all the required potential configurations specified) or it MUST reject the entire session.
Once the answerer has selected a valid and supported offered potential configuration for all of the media streams (or has fallen back to the actual configuration plus any added session attributes), the answerer MUST generate a valid answer SDP as described in RFC 5939 [RFC5939], Section 3.6.2, and further extended below: o Additional answer capabilities and potential configurations MAY be returned in accordance with Section 188.8.131.52. Capability numbers and configuration numbers for those MUST be distinct from the ones used in the offer SDP. o Latent configuration processing and answer generation MUST be performed, as specified below. o Session capability specification for the potential and latent configurations in the answer MAY be included (see Section 3.3.8). Section 3.3.5. o It includes a config-number that is unique in the entire SDP and does not overlap with any potential configuration config-number. o It includes a valid media type ("mt="). o It references a valid transport capability ("t="). o All other capabilities referenced by it are valid. For each such valid latent configuration in the offer, the answerer checks to see if it could support the latent configuration in a subsequent offer/answer exchange. If so, it includes the latent configuration with the same configuration number in the answer, similar to the way potential configurations are processed and the selected one returned in an actual configuration attribute (see RFC 5939 [RFC5939]). If the answerer supports only a (non-mandatory) subset of the parameters offered in a latent configuration, the answer latent configuration will include only those parameters supported (similar to "acfg" processing). Note that latent configurations do not constitute an actual offer at this point in time; they merely indicate additional configurations that could be supported.
If a session capability ("sescap") attribute is included and it references a latent configuration, then the answerer processing of that latent configuration must be done within the constraints specified by that session capability. That is, it must be possible to support it at the same time as any required (i.e., non-optional) potential configurations in the session capability. The answerer may in turn add his own sescap indications in the answer as well. Section 3.6.3 of RFC 5939 [RFC5939] and the further explanation below. When the offerer processes the answer SDP based on a valid actual configuration attribute in the answer, and that valid configuration includes one or more media capabilities, the processing MUST furthermore be done as if the offer was sent using those media capabilities instead of the actual configuration. In particular, the media formats in the "m=" line, and any associated payload type mappings ("rtpmap"), "fmtp" parameters ("mfcap"), and media-specific attributes ("mscap") MUST be used. Note that this may involve use of concatenation and substitution rules (see Sections 184.108.40.206 and 3.3.7). The actual configuration attribute may also be used to infer the lack of acceptability of higher-preference configurations that were not chosen, subject to any constraints provided by a session capability ("sescap") attribute in the offer. Note that the SDP capability negotiation base specification [RFC5939] requires the answerer to choose the highest-preference configuration it can support, subject to local policies. When the offerer receives the answer, it SHOULD furthermore make note of any capabilities and/or latent configurations included for future use, and any constraints on how those may be combined. RFC3264]. If the initiating party has remembered the codecs, potential configurations, latent configurations, and session capabilities provided by the other party in the earlier negotiation, it MAY use this knowledge to maximize the likelihood of a successful modification of the session. Alternatively, the initiator MAY perform a new capabilities exchange as part of the reconfiguration.
In such a case, the new capabilities will replace the previously negotiated capabilities. This may be useful if conditions change on the endpoint.