1. Configuration Guide
  2. Security
  3. Secure Real-Time Transport Protocol
  4. RFC 5939 Support
  5. RFC 5939 Capability Negotiation Attributes

RFC 5939 Capability Negotiation Attributes

The ESBC can use the RFC 5939 based SDP capability negotiation mechanism in which the ESBC generates offers containing multiple potential configurations for a media profile. Each potential configuration has a set of capabilities associated with it. On receiving an answer containing an actual configuration, selected from potential configurations by outbound peer, the ESBC generates an RFC 5939 compliant answer using the highest priority configuration received in the incoming offer from the inbound peer.

A potential SDP configuration may include attribute capabilities and transport capabilities, transport capabilities only, or some other combination of capabilities. If transport capabilities are not included in a potential configuration, the ESBC uses the default transport for that media stream. The actual SDP configuration is the potential configuration that was selected. The selected configuration number and all selected capability numbers used in the actual configuration attribute refer to those from the offer, not the answer.

Key RFC 5939 attribute values used for this support include:

  • Capability negotiation—a=creq:<option-tag-list>
  • Capability negotiation—a=csup:<option-tag-list>
  • Potential config—a=pcfg potential <config-number> [<pot-cfg-list>]
  • Actual config—a=acfg: <config-number> [<sel-cfg-list>]

For all attributes, white space is not allowed before config-number. For a=pcfg, a=acfg, a=tcap and a= acap, the attribute numbering should be in the range of 1 to 2^31-1 (both included).

Operational rules on how the ESBC uses these attributes include the following:

  • Supported Capability Negotiation Extensions Attribute (a=csup)
    • If the incoming offer/answer contains a=csup attribute either at session or media level (one per media description), the ESBC ignores it and continues processing the offer/answer.
    • If the incoming offer/answer contains multiple instances of a=csup attribute at either the session or media level, the ESBC ignores them and continues processing the offer/answer. The RFC states that you can have only one instance of this attribute at the session or the media level (one per media description).
  • Required Capability Negotiation Extensions Attribute (a=creq)
    • If the incoming offer contains a=creq attribute with value other than “cap-v0” either at session or media level (one per media description), the ESBC “488 Not Acceptable Here” as the answer.
    • If the creq contains multiple comma separated values with any of the value other than “cap-v0”, the ESBC generates a “488 Not Acceptable Here” as the answer.
    • If the offer contains more than one instance of a=creq attribute at either session or media level, the ESBC generates a “488 Invalid Session Description” as the answer.
  • Transport Capability Attribute (a=tcap)
    • If there is more than one transport capability attribute at the session level or more than one transport capability attribute in any media description, the ESBC processes the offer based on normal offer/answer rules.
    • If the tcap attribute at session and media level has same trpr-cap-num, the ESBC ignores both the tcap attributes and processes the offer based on normal offer/answer rules.
    • The ESBC ignores any transport capability attribute indicating protocol other than RTP/AVP or RTP/SAVP.
  • Attribute Capability Attribute (a=acap)
    • The ESBC ignores the Attribute capability attribute present at session level.
    • The ESBC only supports the crypto parameter for SRTP as the “acap” attribute at media level. In order for crypto parameter to be considered valid, crypto suite should match one of the currently supported suites. The ESBC ignores any other parameter at media level.
  • Potential Configuration Attribute (a=pcfg)
    • The ESBC ignores potential configuration at the session level, if present.
    • If the potential configuration in the incoming offer contains either delete-attributes (a=-m / a=-s / a=-ms) or extension capabilities, the ESBC ignores that potential configuration and processes the rest of the potential configurations.
    • If the transport protocol configuration list in the potential configuration contains transport protocol other than RTP/AVP or RTP/SAVP, the ESBC ignores that potential configuration and processes the rest of the potential configurations.
    • If the transport capability is not present in potential configuration, the ESBC uses the transport capability specified in the m-line for that potential configuration.
    • If the potential configuration in incoming offer contains comma separated values in “a=” or “t=”, the ESBC ignores that potential configuration and processes the rest of the potential configurations.
  • Actual Configuration Attribute (a=acfg)
    • The ESBC ignores actual configuration attributes if present at the session level.
    • If multiple instances of the actual configuration attribute are present for a media description, the ESBC ignores all except the first instance.
    • If the actual configuration in the received answer contains either delete-attributes (a=-m / a=-s / a=-ms) or extension capabilities, the ESBC ignores the actual configuration and uses normal offer/answer rules.
    • If the actual configuration in the received answer contains multiple transport protocols (“t=”) in pipe separated or comma separated form, the ESBC ignores the actual configuration and uses normal offer/answer rules.
    • If the actual configuration in the received answer contains multiple capabilities (“a=”) in pipe separated or comma separated form, the ESBC ignores the actual configuration and uses normal offer/answer rules.