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

RFC 5939 Capability Negotiation Attributes

The SBC can use the RFC 5939 based SDP capability negotiation mechanism in which the SBC 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC 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 SBC “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 SBC 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 SBC 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 SBC processes the offer based on normal offer/answer rules.
    • If the tcap attribute at session and media level has same trpr-cap-num, the SBC ignores both the tcap attributes and processes the offer based on normal offer/answer rules.
    • The SBC ignores any transport capability attribute indicating protocol other than RTP/AVP or RTP/SAVP.
  • Attribute Capability Attribute (a=acap)
    • The SBC ignores the Attribute capability attribute present at session level.
    • The SBC 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 SBC ignores any other parameter at media level.
  • Potential Configuration Attribute (a=pcfg)
    • The SBC 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 SBC 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 SBC ignores that potential configuration and processes the rest of the potential configurations.
    • If the transport capability is not present in potential configuration, the SBC 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 SBC ignores that potential configuration and processes the rest of the potential configurations.
  • Actual Configuration Attribute (a=acfg)
    • The SBC 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 SBC 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 SBC 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 SBC 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 SBC ignores the actual configuration and uses normal offer/answer rules.