RFC 5939 Support

You can configure the SBC to support RFC 5939-based SDP capability negotiation. This support overrides the supported RFC 3264-based mechanism for generating mixed RTP/SRTP offers to better support secure and non-secure flows in the same realm. Within the RFC 3264 model, both the offer and answer contain actual configurations, but separate capabilities and potential configurations are not supported. The RFC 5939 implementation on the SBC is backward compatible and uses the RFC 3264-based model by default.

RFC 5939 addresses both attribute and transport capability negotiation by offering potential configurations. For transport, this contrasts with the RFC 3264 method, which presents separate RTP and SRTP offers and allows the end-station to set one to port number 0. One of the primary uses of RFC 5939 by the SBC is generating and supporting mixed RTP/SRTP offers.

When configured, the SBC generates RFC 5939-compliant offers when it receives initial INVITE, UPDATE or Re-INVITE messages. These offers contain multiple potential configurations for a media profile. Each potential configuration has a set of capabilities associated with it. The receiver chooses one of the potential configurations and sends it back in answer as the configuration for that media profile. On receiving the answer from the outbound peer, the SBC generates an RFC 5939-compliant answer using the highest priority configuration received in the incoming offer from the inbound peer. If the answer to an RFC 5939-compliant offer is not RFC 5939 compliant, the SBC reverts to the RFC 3264 method.

To enable RFC 5939 compliant offer generation, set the egress-offer-format parameter in the applicable sdes-profile to rfc5939-compliant. In addition, you must set either the applicable inbound or outbound media-security-policy, mode parameter to any.

The SBC does not support RFC3264 mixed mode offers and RFC5939 compliant offer in the same realm. Create a separate realm to support RFC5939 and assign a dedicated media-security-policy that has an associated sdes-profile with the egress-offer-format set to rfc5939-compliant, to that realm.

RFC 5939 Operation

The SBC complies with RFC 5939, but its behavior is dependent upon your configuration. This section describes the SBC behaviors relative to specific points in the call flow.

The SBC considers an offer RFC 5939 compliant if it includes a potential configuration attribute (a=pcfg).

Incoming Offer

The SBC processes the incoming initial INVITE, re-INVITE or UPDATE message containing RFC 5939 compliant offer based on the media-security-policy, inbound, mode parameter associated with the inbound realm as follows:

  • rtp—The SBC does not process any RFC 5939 compliant offer and rejects the session with “488 Not Acceptable Here”.
  • srtp—The SBC does not process any RFC 5939 compliant offer and rejects the session with “488 Not Acceptable Here”.
  • any:
    • The SBC only accepts an SDP offer containing an actual or at least one valid potential configuration having RTP/AVP or RTP/SAVP protocol. Otherwise, it rejects the session with a 488 Not Acceptable Here.
    • If all potential configurations present in the received offer contain unsupported transport capability or an unsupported crypto attribute., the SBC processes the received offer as a normal offer/answer.
    • If all potential configurations present in the received offer contain either delete-attributes (a=-m / a=-s / a=-ms) or extension capabilities, the SBC processes the received offer as normal offer/answer
    • The SBC parses and stores one valid, highest priority configuration for both the RTP and SRTP protocols, if available, from the list of potential configurations.

When selecting a potential configuration for SRTP, the priority of the potential configuration takes precedence over the priority of the configured cryptography suites.

Outgoing Offer

The SBC generates the outgoing RFC 5939 compliant offer based on the setting of:

  • The media-security-policy, outbound, mode parameter associated with the outbound realm and:
  • The egress-offer-format in the sdes-profile associated with the media-security-policy.

SBC behavior, based on the outbound media security policy mode, includes:

  • rtp:
    • If the incoming offer is in non-RFC 5939 format, the SBC follows RFC 3265 behavior.
    • If the incoming offer is in RFC 5939 format:
      • And the actual or a valid potential configuration contains only RTP/AVP for a media line, the SBC generates a non RFC 5939 format offer with the RTP/AVP media line.
      • And the actual or a valid potential configuration contains only RTP/SAVP, the SBC generates a non RFC 5939 format offer after converting the RTP/SAVP to RTP/AVP media line.
      • And the actual and valid potential configuration contains both RTP/AVP and RTP/SAVP protocol for a media line, the SBC generates a non RFC 5939 format offer with the RTP/AVP media line.
  • srtp:
    • If the incoming offer is in non-RFC 5939 format, the SBC follows RFC 3264 behavior.
    • If the incoming offer is in RFC 5939 format, the SBC behaves as follows:
      • If the actual or valid potential configuration contains only RTP/SAVP for a media line, the SBC generates a non RFC5939 format offer with an RTP/SAVP media line.
      • If the actual or a valid potential configuration contains only RTP/AVP, the SBC generates a non RFC5939 format offer after converting the RTP/AVP to RTP/SAVP media line.
      • If the actual and valid potential configuration contains both RTP/AVP and RTP/SAVP protocol for a media line, the SBC generates a non RFC 5939 format offer with an RTP/SAVP media line.
  • any—The SBC creates offer SDP based on the value configured in the egress-offer-format set in the sdes-profile configuration:
    • If the incoming offer is not in RFC 5939 format, the SBC behaves as follows:
      • If the value is same-as-ingress, the SBC leaves the profile of the media lines unchanged.
      • If the value is simultaneous-best-effort, the SBC behaves as follows:
        • Adds an RTP/SAVP media line for any media profile that has only the RTP/AVP media profile.
        • Adds an RTP/AVP media line for any media profile that has only the RTP/SAVP media profile.
        • Should the media profile in the incoming offer SDP already have two media lines (one for RTP/AVP and on for RTP/SAVP), the SBC does not have to make these additions. Instead, it maps the media lines in the answer it receives with the media lines from the incoming offer SDP. It also ensures that the media lines in the answer SDP it sends match the media lines from the incoming offer SDP.
      • If the value is RFC 5939-compliant, the SBC generates an RFC 5939 compliant offer containing actual configuration with RTP/AVP protocol and potential configuration with RTP/SAVP protocol.
    • If the incoming offer is in RFC 5939 format, the SBC behaves as follows:
      • If the value is simultaneous-best-effort, the SBC generates a non RFC5939 compliant offer with two m-lines, one with RTP/AVP and other with RTP/SAVP protocol.
      • If the value is rfc5939-compliant, the SBC generates an RFC5939 compliant offer containing the actual configuration with RTP/AVP protocol and a potential configuration with RTP/SAVP protocol.
While generating an RFC 5939 compliant offer, the SBC populates the RFC 5939 specific attributes as follows:
  • Adds a transport capability attribute at the session level, appearing as a=tcap:1 RTP/SAVP
  • Adds a new potential configuration for each configured crypto attribute at the media level. Examples include:
    • a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32 inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32

      a=pcfg:1 t=1 a=1

    • a=acap:2 crypto:2 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:4

      a=pcfg:2 t=1 a=2

Note:

While adding potential configurations, the SBC assigns priority to “a=pcfg” based on the priority of the configured crypto suites in the sdes-profile associated with outgoing media-security-policy.

Incoming Answer

The SBC processes the incoming answer based on the format of the outgoing offer generated by the SBC as follows:

  • If the incoming answer is not RFC5939 compliant, then process answer as per normal offer/answer rules as is defined in RFC 3264.
  • If the incoming answer is RFC 5939 compliant, then:
    • For each media description in incoming answer, for which a potential configuration was included in outgoing offer, the SBC ensures that the config-number in the actual configuration attribute (“a=acfg”) matches the config-number of the potential configuration attribute (“a=pcfg”) of the outgoing offer. Also the att-cap-num and trpr-cap-num in the actual configuration must match the attribute and transport capability present in the potential configuration of the outgoing offer:
      • If the actual configuration satisfies these conditions, use the capability attributes and transport capability attribute as per actual configuration.
      • If the actual configuration for a media description doesn't satisfy the conditions mentioned in the above point, process answer as per normal offer/answer rules.

Note:

If “a=acfg” attribute in incoming answer contains “t=” with more than one value (say a=acfg:1 t=1,2 or a=acfg:1 t=1|2), the SBC treats the actual configuration as invalid and the answer with normal offer/answer rules.

Note:

If “a=acfg” attribute in incoming answer contains “a=” with more than one value (say a=acfg:1 t=1 a=1,2 or a=acfg:1 t=1 a=1|2), the SBC treats the actual configuration as invalid and treats the answer with normal offer/answer rules.

Outgoing Answer

The SBC generates the outgoing answer based on the format of the incoming offer from the ingress peer and the mode configured in the media-security-policy associated with the inbound realm as follows:

  • If the incoming offer was not RFC 5939 compliant, having a single m-line with RTP or SRTP protocol (media-security-policy associated with inbound realm has mode set to rtp or srtp or any), then the SBC generates a non RFC 939 compliant answer having a single m-line with the RTP or SRTP protocol based on the configured mode using the answer received from the egress peer.

    If the answer received from egress peer is in RFC 5939 format, then the SBC uses the m-line present in the RFC 5939 compliant answer to generate the outgoing answer.

  • The following assume you have configured the SBC with the media-security-policy associated with inbound realm has mode set to any.
    • If the incoming offer was not RFC 5939 compliant, having two m-lines with both RTP and SRTP protocols, then the SBC generates a non RFC 5939 compliant answer having two m-lines with the RTP and SRTP protocols based on the configured mode using the answer received from the egress peer.

      If the answer received from the egress peer is in RFC 5939 format, then the SBC uses the m-line present in the RFC 5939 compliant answer to generate the outgoing answer.

    • If the incoming offer was RFC 5939 compliant, then the SBC generates an RFC 5939 compliant answer using the highest priority configuration present in the offer received from the inbound peer and the configuration associated with the inbound realm.

      If outgoing answer is generated based on the actual configuration rather than a potential configuration received in the incoming offer, then the SBC generates an answer that is not RFC 5939 compliant.

    • If the incoming offer was RFC 5939 compliant, but with all unsupported attributes in the potential configuration, then the SBC generates an answer that is not RFC 5939 compliant, using the actual configuration present in the offer received from the inbound peer and the configuration associated with the inbound realm.

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.

RFC 5939 Configuration

This setting provides support for RFC 5939.

To configure SDES profile parameters:

  1. From superuser mode, use the following command sequence to access sdes-profile configuration mode. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# media-security
ORACLE(media-security)# sdes-profile
ORACLE(sdes-profile)#
  2. Set the egress-offer-format parameter to rfc5939-compliant. 
     ORACLE(sdes-profile)#egress-offer-format rfc5939-compliant
  3. Use done, exit, and verify-config to complete configuration of this compliance.