Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6871

Session Description Protocol (SDP) Media Capabilities Negotiation

Pages: 55
Proposed Standard
Updates:  5939
Part 3 of 4 – Pages 35 to 44
First   Prev   Next

Top   ToC   RFC6871 - Page 35   prevText

3.4. Offer/Answer Model Extensions

In this section, we define extensions to the offer/answer model defined in RFC 3264 [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.

3.4.1. Generating the Initial Offer

The media capabilities negotiation extensions defined in this document cover the following categories of features: 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 description of the operation is as follows: When an endpoint generates an initial offer and wants to use the functionality described in the current document, it SHOULD identify and define the media formats and associated parameters it can support via the "rmcap", "omcap", "mfcap", and "mscap" attributes. The SDP media line(s) ("m=") should be made up with the actual configuration
Top   ToC   RFC6871 - Page 36
   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. Offer with Media Capabilities
For each RTP-based media format the offerer wants to include as a media format capability, the offer MUST include an "rmcap" attribute for the media format as defined in 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
Top   ToC   RFC6871 - Page 37
   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; payload type escaping may be
   used in "mfcap", "mscap", and "acap" attributes as defined in Section
Top   ToC   RFC6871 - Page 38
   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. Offer with Latent Configuration
If the offerer wishes to offer one or more latent configurations for future use, the offer MUST include a latent configuration attribute ("lcfg") for each as defined in 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. Offer with Configuration Combination Restrictions
If the offerer wants to indicate restrictions or preferences among combinations of potential and/or latent configurations, a session capability ("sescap") attribute MUST be provided at the session level for each such combination as described in Section 3.3.8. Each "sescap" attribute MUST include a session-num that is unique in the
Top   ToC   RFC6871 - Page 39
   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.

3.4.2. Generating the Answer

When receiving an offer, the answerer MUST check the offer for "creq" attributes containing the value "med-v0"; answerers compliant with this specification will support this value in accordance with the procedures specified in RFC 5939 [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.
Top   ToC   RFC6871 - Page 40
   Below we provide a more detailed normative description of how the
   answerer processes the offer SDP and generates an answer SDP. Processing Media Capabilities and Potential Configurations
The answerer MUST first determine if it needs to perform media capability negotiation by examining the SDP for valid and preferred potential configuration attributes that include media configuration parameters (i.e., an "m" parameter in the "pcfg" attribute). Such a potential configuration is valid if 1. It is valid according to the rules defined in RFC 5939 [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 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
Top   ToC   RFC6871 - Page 41
   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

   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.
Top   ToC   RFC6871 - Page 42
   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  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). Latent Configuration Processing
The answerer MUST determine if it needs to perform any latent configuration processing by examining the SDP for valid latent configuration attributes ("lcfg"). An "lcfg" attribute is considered valid if: o It adheres to the description in 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.
Top   ToC   RFC6871 - Page 43
   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.

3.4.3. Offerer Processing of the Answer

The offerer MUST process the answer in accordance with 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 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.

3.4.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 can do so via the mechanisms defined for offer/answer [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.
Top   ToC   RFC6871 - Page 44
   In such a case, the new capabilities will replace the previously
   negotiated capabilities.  This may be useful if conditions change on
   the endpoint.

(page 44 continued on part 4)

Next Section