In this section:
The SBC Core supports downstream forking call flows when dialog transparency is enabled. The following functionality is supported.
Multiple early dialogs at ingress leg when dialog transparency is enabled. It relays each forked 18x response received for the INVITE at egress leg towards the ingress leg by transparently passing the Call-ID, "From" tag, and "To" tag thus exposing multiple early dialogs at ingress leg.
The offer/answer negotiation on a forked call depends on the Packet Service Profile configured on either legs. As a result, SDP sent in the forked 18x response(s) towards ingress leg may vary depending on whether pass-through mode or transcoding mode is selected by the SBC. The SBC continues to use the same media IP/Port that is sent in the first 18x SDP for all the forked 18x messages sent towards the ingress leg. Before sending a forked 18x response towards ingress leg, the SBC sends UPDATE on the previous early dialog with SDP that contains "a=inactive" line. This is performed to prevent ingress peer from sending media on all the early dialogs exposed by the SBC. With this call flow, media is expected only on the last active early dialog exposed by the SBC.
The following diagram is an example call flow scenario for downstream forking with dialog transparency.
Downstream forking with dialog transparency call flow
Call-ID and From tag are assumed to be same in all the responses shown in the above call flow.
Note
The SBC exposes multiple early dialogs on the ingress if multiple early dialogs are present on the egress due to downstream forking.
Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
The SBC retains all the early dialog contexts, even after a forked call is answered or connected with 200 OK and ACK for 32 seconds. The SBC handles all inactive early dialogs as follows:
The SBC clears any existing early dialogs automatically after 32 seconds.
The parameters dialogTransparency
and downstreamForkingSupport
must be enabled to perform these functionalities.
The following diagram is an example call flow scenario for preserving early dialog context after 200 OK for INVITE.
Preserving Early Dialog Context After 200 OK for INVITE Call Flow
The SBC supports UPDATE with Session Description Protocol (SDP) both for active and inactive early dialogs before a final 200 OK for INVITE is received.
The parameters dialogTransparency
and downstreamForkingSupport
must be enabled to perform these functionalities.
The following diagram is an example call flow scenario for support for UPDATE with codec change on inactive early dialog.
Support for UPDATE with Codec Change on Inactive Early Dialog Call Flow
The SBC retains the call, but deactivates media resources when all the early dialogs are cleared for a forked call either due to 199 or BYE response.
The parameters dialogTransparency
and downstreamForkingSupport
must be enabled to perform these functionalities.
The following diagram is an example call flow scenario for deactivating media resources when early dialogs do not exist.
Deactivate Media Resources When Early Dialogs Do Not Exist Call Flow