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

RFC 5939 Operation

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

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

Incoming Offer

The ESBC 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 ESBC does not process any RFC 5939 compliant offer and rejects the session with “488 Not Acceptable Here”.
  • srtp—The ESBC does not process any RFC 5939 compliant offer and rejects the session with “488 Not Acceptable Here”.
  • any:
    • The ESBC 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 ESBC 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 ESBC processes the received offer as normal offer/answer
    • The ESBC 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 ESBC 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.

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

  • rtp:
    • If the incoming offer is in non-RFC 5939 format, the ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC follows RFC 3264 behavior.
    • If the incoming offer is in RFC 5939 format, the ESBC behaves as follows:
      • If the actual or valid potential configuration contains only RTP/SAVP for a media line, the ESBC 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 ESBC 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 ESBC generates a non RFC 5939 format offer with an RTP/SAVP media line.
  • any—The ESBC 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 ESBC behaves as follows:
      • If the value is same-as-ingress, the ESBC leaves the profile of the media lines unchanged.
      • If the value is simultaneous-best-effort, the ESBC 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 ESBC 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 ESBC 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 ESBC behaves as follows:
      • If the value is simultaneous-best-effort, the ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC processes the incoming answer based on the format of the outgoing offer generated by the ESBC 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 ESBC 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 ESBC 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 ESBC treats the actual configuration as invalid and treats the answer with normal offer/answer rules.

Outgoing Answer

The ESBC 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 ESBC 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 ESBC uses the m-line present in the RFC 5939 compliant answer to generate the outgoing answer.

  • The following assume you have configured the ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC 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 ESBC 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.