Call Flows for Hiding Session Updates

This section shows call flows where the SBC is configured with hsu-policy to hide session updates.

For simplicity, the images omit details that would be present in the actual call flow, but are not important for the use case. For example, only some show the specific codecs or headers included on the messages, and most omit codec-policy configurations.

Hiding reINVITEs with SDP Changes

The following image shows the call flow when:

  • The SBC acting as UAS has codec-policy configured with allow-codecs set to PCMU:no * (not shown in the figure).
  • The SBC acting as UAC has:
    • hsu-policy configured with hsu-reinvite-sdp-except-hold-resume enabled
    • codec-policy configured with add-codecs-on-egress set to g729 (not shown in the figure).

In this flow, when the UAC sends a reINVITE with updated SDP, the SBC does not send the reINVITE on to the UAS. Instead, the SBC responds with 200 OK. The SBC continues to enforce the configured codec-policy.


The image shows the SBC hiding session updates when SDP changes on a reINVITE.

Hiding Offerless reINVITES

The following image shows the call flow when the hsu-policy on the SBC acting as UAC is configured with hsu-reinvite-offerless enabled. In this flow, when the UAC sends a reINVITE with no SDP, the SBC does not send the reINVITE on to the UAS. Instead, the SBC responds with 200 OK.


The image shows the SBC hiding session updates when a reINVITE with no SDP is sent.

Hiding reINVITEs with Unchanged Headers

The following image shows the call flow when the hsu-policy on both sides of the SBC is configured with hsu-headers set to P-Asserted-Identity. In this flow, when either side sends a reINVITE with the same P-Asserted-Identity header (123@example.com on the UAC side, 456@example.com on the UAS side), the SBC does not send the reINVITE on. Instead, the SBC responds with 200 OK.


The image shows the SBC hiding session updates when the header is unchanged.

Applying the Ingress-Side Policy

The following image shows the call flow when each side of the SBC has a different hsu-policy configured, and the initial INVITE contains the P-Acme-Hsu-Ingress header, added by Session Router. When this header is present in the initial INVITE, the SBC applies the ingress-side hsu-policy for any UPDATE or reINVITE received from the same direction as the initial INVITE that contained the header. This image also shows the UPDATE flow when PRACK is involved.

In the image, when the UAC sends an UPDATE, the SBC applies hsu-policy 1 rather than hsu-policy 2. When the UAS sends a reINVITE, because this is from the opposite direction from the INVITE with the header, the SBC applies hsu-policy 1. The SBC does not send the UPDATE or reINVITE on. Instead, the SBC responds with 200 OK.


The image shows the SBC hiding session updates according to the ingress hsu-policy when the P-Acme-Hsu-Ingress header is present.

Hiding reINVITEs and Forcing Transcoding

The following image shows the call flow when the hsu-policy on both sides of the SBC is configured with hsu-force-xcode enabled.

In the image, the call is established as normal with transcoding. When the UAC sends a reINVITE with new audio codecs, the SBC does not send the reINVITE on. Instead, the SBC responds with 200 OK that includes the top codec. Even though the reINVITE contains a matching codec, because hsu-force-xcode is enabled, the SBC forces transcoding with the top codec.


The image shows hiding session updates and enforcing transcoding with the first codec.

Hiding reINVITEs and Forcing ptime

The following image shows the call flow when the hsu-policy on both sides of the SBC is configured with the following parameters:
  • hsu-reinvite-sdp-except-hold-resume: enabled
  • hsu-force-xcode: disabled
  • hsu-force-ptime: enabled
In this flow:
  1. The initial call is established using transcoding and transrating to work with different codecs and ptimes.
  2. The UAC sends a reINVITE with a codec and ptime that matches what the UAS is using. Instead of sending the reINVITE on, the SBC responds with a 200 OK that includes the common codec and ptime, and continues the call with no transrating or transcoding.
  3. The UAS sends a reINVITE with a codec and ptime that no longer match. Instead of sending the reINVITE on, the SBC responds with a 200 OK that includes the top codec and new ptime from the reINVITE, and continues the call with transcoding and transrating.

The image shows the call flow for hiding session updates and enforcing a common ptime.

SRTP: Hiding reINVITEs for Single-Ended SRTP Termination

The following image shows the call flow when hsu-policy is configured on the SBC acting as UAC, and media-sec-policy is configured on the SBC acting as UAS. In this flow, when the UAC sends a reINVITE with updated key on the a=crypto line, the SBC does not send the reINVITE on to the UAS. Instead, the SBC responds with 200 OK containing an updated key.


The image shows hiding session updates for single-ended SRTP termination.

SRTP: Hiding reINVITEs for Back-to-Back SRTP Termination

The following image shows the call flow when hsu-policy is configured on the SBC acting as UAC, and a different media-sec-policy is configured on both sides of the SBC. In this flow, when the UAC sends a reINVITE with the same key on the a=crypto line, the SBC does not send the reINVITE on to the UAS. Instead, the SBC responds with 200 OK containing the original key from the UAS.


The image shows hiding session updates for back-to-back SRTP termination.

Even if the key in the reINVITE were different, the SBC still would not send on the reINVITE. Instead, the SBC would generate its own key and add that to the 200 OK response.

SRTP: Hiding reINVITEs for SRTP Pass-Through

The following image shows the call flow when hsu-policy is configured on the SBC acting as UAC, and a media-sec-policy is configured with pass-through enabled on both sides of the SBC.

In this flow, when the UAC sends a reINVITE with the same key on the a=crypto line, the SBC does not send the reINVITE on to the UAS. Instead, the SBC responds with 200 OK containing the original key from the UAS.


The image shows hiding session updates for SRTP pass-through when the keys are the same.

However, if the key in the reINVITE were different, because pass-through is enabled, the SBC would send the reINVITE on to the UAS to get a new key and re-establish the encryption, as shown in the following image.


The image shows allowing session updates when pass-through is enabled and the key is different.

Allowing reINVITES with New Media

The following image shows the call flow when the hsu-policy on both sides of the SBC is configured and one side sends a reINVITE that includes new media. In the image, the initial call is established with audio, and then UAS side sends a fax. The reINVITE includes a new m-line, m=image udptl t38.

In this case, even though an hsu-policy is configured, the SBC passes on the reINVITE to establish the fax call. Then the call proceeds as normal, either with the UAC accepting the fax (Flow A), or with the UAC rejecting the fax and continuing with the previously-established media (Flow B).


The figure shows allowing session updates that add new media.