You can configure the SBC to bypass gating and forward early media to untrusted domains. This feature resolves early media problems for situations including PEM gating when an UPDATE goes from the trusted side towards the untrusted side and the system prevents an early media announcement to play through the subsequent 18x. In this case, the default SBC behavior would be to gate the early media. To configure this feature, you enable the pass-pem-in-update option on the ingress sip-interface.

The SBC supports the SIP P-Early-Media (PEM) header and function used within SIP INVITE, PRACK, and UPDATE requests and responses to authorize the use of early media. Standard and default SBC behavior includes preventing early media signaling from entering networks that are not authorized or are not trusted. In some deployments, however, administrators may want early media forwarded even if the network is not trusted.

The SBC uses two key sip-interface parameters to control early media, including p-early-media-header and p-early-media-direction. Both of these parameters are effectively disabled by default, which gates early media from operating across the interface. In addition, you can set the trust-mode according to your setup (none, all, agents and so on), which establishes multiple security behaviors on the interface, including gating early media from a trusted source.

The call flow below presents an example of the issues this feature resolves. In this flow, the SBC closes the gate on early media when it receives the 200 OK to the UPDATE from the mobile originating (MO) side, depicted within the dashed box. This is default SBC behavior, resulting in PEM being inactive on the access side, and, in this call flow, prevents the presentation of early media on the MO leg.

An example of a problem case solved by this features includes the SBC receiving an UPDATE with a PEM header arriving from the trusted mobile terminating (MT) leg/core side. Without this feature, the SBC follows its default behavior, which includes not forwarding the PEM header towards the untrusted access side:

• If you set the p-early-media-header access sip-interface to modify and the p-early-media-direction is inactive, the 200 OK response to the update from the MO effectively closes the gate.
• The SBC closes the gate when receiving the 200 OK to the UPDATE from the MO side, which is by design (PEM inactive on access), thereby gating early media on the MO leg. In this case, the access is always untrusted, and the core is always trusted.

When you configure the pass-pem-in-update option, the SBC forwards the PEM header as received, ignoring other PEM header configuration. The applicable messages that can trigger this feature include the SBC:

• Receiving an UPDATE request from the trusted side and forwarding it towards the untrusted side.
• Receiving a 200 OK/UPDATE from the untrusted side and forwarding it towards the trusted side.

ORACLE(sip-interface)# +options pass-pem-in-update

The image below depicts the SBC supporting PEM across trusted and untrusted networks in both directions. You have configured the trust-mode to none, the p-early-media-header to modify, and the p-early-media-header to inactive on the access sip-interface. You have also set the p-early-media-header to disabled and the trust-mode to all on the egress sip-interface. Both of these configurations prevent early media across those interfaces.

But you have also enabled the pass-pem-in-update option on the ingress sip-interface, which would be applied to the UPDATE coming from the core (access interface egress), based on the egress sip-interface configuration. This configuration supersedes the other configurations, allowing the SBC to accept early media, effectively bypassing what would be the standard SBC behavior of rejecting it.

This feature is compatible with the multiple early dialogs feature within the context of dialog merging, and many-to-many dialogs. You establish these configurations with the merge-early-dialogs configuration and the multiple-dialogs-enhancement option respectively. Applicable cases wherein the SBC receives an UPDATE from the trusted side allows early media include:

• multiple-early-dialogs in many-to-many mode cases:
  • UN-TRUSTED (ingress side ) to TRUSTED (egress side )
  • UN-TRUSTED (egress side ) to TRUSTED (ingress side )
• multiple-early-dialogs in merge mode cases, with the ingress configured as the merge realm:
  • UN-TRUSTED (ingress side ) to TRUSTED (egress side )
  • TRUSTED (ingress side ) to UN-TRUSTED (egress side )

  Note:

  This is supported in E2E precondition cases because the SBC responds to an UPDATE message from the calling party locally in the context of the merge.