SIP Forking Support

Overview

An enterprise SIP Trunking solution requires the networking nodes to inter-operate with different endpoints as well as with service provider for PSTN breakout. This functionality can be achieved by call forking to multiple destinations. SIP forking refers to the capability to alert several devices of the same subscriber or to be able to alert one or more devices each of several different subscribers as a part of a session setup. The sequence of alerting itself can be in parallel (allowing any of the devices to receive the session), or in sequence (in which case a precedence is already specified in the order of forking).

In the context of reaching more than one subscriber, forking is typically initiated by an Application Server (AS) executing a subscribed call service (e.g. “Hunt Group”). Whereas forking to reach more than one registered device for the same subscriber can be done by the SIP registrar itself.

SIP allows either of the above types of forking to be done in a “B2BUA” manner - in which case call-leg for each terminating device has a unique call identifier. Also, either of the above types of forking could be done in a “forking proxy” manner - in which case call-leg for each terminating device has the same Call-ID and From-tag, but would have a different To-tag selected by the device being alerted.

The SBC (as terminating SBC/P-CSCF) supports receiving multiple initial forked requests with the same Call-ID, CSeq and From-tag, but with different Request-URIs. Each of these requests are treated as a new dialog establishment request, and is permitted to proceed in parallel.

Any out of dialog request terminating to the UA may be forked by the registrar or the AS. The SBC supports Upstream forking for the SIP INVITE and out of dialog SIP requests such as OPTIONS, SUBSCRIBE, MESSAGE and REFER.

Forking Behavior

This section describes the transaction matching logic used by the SBC to determine if an ingress SIP request is one of the following:

• An initial request for a new dialog,
• An overlap dialing request,
• A forked request, or
• A merged/looped request.

Additionally, for the below matching logics, Request-URI comparison is accomplished as follows:

• For a SIP URI userinfo, host portion and Port of the Request-URI of the incoming request is compared with userinfo, host portion and Port of the previous request Request-URI.
• For a tel URI and SIP URI with user=phone parameter, userinfo and phone-context of the Request-URI of the incoming request is compared with userinfo and phone-context of the previous request Request-URI.

Overlap Dialing Request

The SBC processes multiple INVITEs for the same call with additional digits to complete the dial sequence resulting in a successful route. The SBC also supports Info-based overlap dialing where initial INVITE with incomplete called party digits is answered locally by the SBC to establish early dialog, and subsequent digits are received through INFO message to complete dial sequence resulting in a successful route.

The SBC treats an ingress SIP request as an overlap dialing request from an endpoint if it appears similar to a previously received ingress SIP request (for which a call-leg is presently in progress), and if it satisfies all the following conditions:

• Topmost Via Contains a different branch parameter value
• Contains same From-tag, Call-ID and CSeq method
• Does not contain a To-header tag
• Contains a different CSeq number from the previously received SIP request
• Contains a Request-URI different from the previously received SIP request

To configure Overlap Addressing service for a SIP Trunk Group from the CLI, see SIP Trunk Group - Services - CLI.

Interworking is supported between SIP/H.323 and H.323/SIP clients where H.323 side is configured for overlap or enbloc, and SIP side is configured for supporting Multi Invite/Info or enbloc.

Forked Request

The SBC treats an ingress SIP request as a forked request if it appears similar to a previously received ingress SIP request (for which a call-leg is presently in progress), and if it satisfies all the following conditions:

• Topmost Via Contains a different branch parameter value
• Contains same From-tag, Call-ID and CSeq (number as well as method being equivalent)
• Does not contain a To-header tag
• Contains a Request-URI different from the previously received SIP request.

Merged Request

The SBC treats an ingress SIP request as a merged request if it appears similar to a previously received ingress SIP request (for which a call-leg is presently in progress), and if it satisfies all the following conditions:

• Topmost Via Contains a different branch parameter value
• Contains same From-tag, Call-ID and CSeq (number as well as method being equivalent)
• Does not contain a To-header tag
• Contains a Request-URI same as the previously received SIP request.

Looped Request

The SBC treats an ingress SIP request as a looped request if it appears similar to a previously received ingress SIP request (for which a call-leg is presently in progress), and if it satisfies all the following conditions:

• Topmost Via Contains a different branch parameter value
• Contains same From-tag, Call-ID and CSeq (number as well as method being equivalent)
• Does not contain a To-header tag
• Contains an earlier Via header having the SBC IP address and a branch parameter value indicating that the previous Request-URI is same as received ingress Request-URI.

Downstream Forking

The SBC, acting as B2BUA, exhibits following downstream forking behavior:

• Terminates forked dialogs on the egress call leg, shielding caller from signaling related to call forking.
• Uses a ‘Early Media Selection Profile’ to control the cut-thru behavior for such scenarios.
  • Media selection can happen based on P-Early-Media header value received in 18x or UPDATE.
  • Latest or first provisional response can be used for media selection.
• Honors the SDP answer received in 18x on the same dialog as active dialog.
• Honors the SDP answer received in 18x response on a different dialog than the active dialog.
• Uses UPDATE towards the caller to indicate the new offer received in a 18x.
• On receipt of a final response from the egress entity, forwards the same on ingress leg.

When a downstream forking entity sends a 199 response code for a particular early dialog, the SBC will have to consume the same, as the ingress leg is being shielded from the call-forking related signaling and instead just clear the corresponding early dialog context. If the early dialog on which the 199 is received is NOT being used for cut-through, there is no impact other than clearing the context. If the early dialog on which the 199 is received is being used for cut-through, the cut-through will be removed apart from clearing the context.

The following SBC behavior occurs when the parameter "Downstream Forking Supported" is enabled on the egress leg:

• Accepts up to ten 18x responses for the same INVITE request having different to-tag values.
• Accepts the first received final response as the final response for the INVITE transaction and generates messages on the other leg accordingly.
• If a 2xx response is received for any early dialog, replies with an ACK message and the dialog is terminated by sending a BYE immediately.
• If a provisional response creating an early dialog is received, and if that response causes RTP cut through to change to another early-dialog than the previous one, a new session offer with UPDATE is generated on the ingress leg if the new session answer impacts the codec on the ingress leg.
• If the call needs to be terminated, for example if a CANCEL/BYE request is received on the ingress leg before a final response is received for any early dialog, generates a single CANCEL request regardless of the number of early dialogs at that time. The Request-URI, Call-Id, To, the numeric part of the CSeq, and From header fields of the CANCEL request is equivalent to the corresponding INVITE request.

The cut-through for Downstream Forking is defined based on:

• pemPriority—PEM (Privacy Enhanced Mail) based. Cut-through occurs based on the value of the PEM header (default value is “sendrecv” if not configured).
• firstProvResponse—First Reliable Provisional response. Cut-through for first provisional response, and suppress the rest until final response is received.
• lastReceivedSdp—Cut-through based on last received SDP.

While receiving SDP answers in 18x responses, the SBC gracefully handles 18x responses by:

• accepting the SDP answer received in 18x on same dialog as active dialog (to support media redirection case),
• accepting the SDP answer received in 18x response on different dialog than the active dialog (forking case),
• or not sending modified SDP answer in 18x response, and instead sending the new offer towards the caller using SIP UPDATE (early dialog).

The SBC supports transcoding active early media from subsequent 18x responses from different dialogs if the ingress peer does not support 100rel to ensure the ingress peer receives what is expected as per SDP negotiations.

• If the SBC is configured for "Downstream Forking" and to accept the Last Provisional Response (default value), and multiple 18xs from different sources are received on egress peer, the SBC does not change the early media on ingress leg. For any subsequent changes in an active early media on egress peer, the SBC makes the call as either pass-through or transcoded accordingly without changing the codec on the ingress early dialog.
• If the codec received in a subsequent 18X response from the egress peer is the same as what was sent in the first 18X response on the ingress side, then SBC makes the call as a pass-through call.
• If the codec received in a subsequent 18X response from egress peer is different from what was sent in the first 18X response on the ingress side, the SBC forces the call to transcode even though pass-through is possible.
• Once a call becomes stable, the SBC initiates a re-INVITE on the ingress peer, as needed, for updating any additional SDP changes.
• If the ingress endpoint does not support 100rel, the SBC retains the same codec on the ingress endpoint without any change when "Dialog ID Transparency" configuration is enabled.
• If the ingress endpoint supports 100rel, there is no change to existing SBC functionality when "Dialog ID Transparency" feature is enabled.
• The SBC continues to stay in the call when it is unable to do transcoding for an early dialog and it retains the same early media that was currently active.
• The SBC gracefully terminates the call if a final answer is received on an early dialog for which transcoding is not supported.
• The SBC does not trigger this feature if the SBC is configured for "Down Stream Forking" and to accept the First Provisional Response.

Application Layer Forking

The SBC Core supports Application Layer Forking feature to receive a single initial INVITE at the ingress leg and send multiple INVITEs with different Call-IDs to different destinations on the egress leg. The first answered call is considered as active, and the SBC terminates the other calls gracefully by sending a CANCEL message. The SBC exposes a single dialog and a single media stream on the ingress leg while forking to multiple dialogs and exposing multiple media streams on the egress leg.

If different end devices with unique Address of Records (AoRs) in an enterprise exist, the SBC maintains an AoR group to perform Call Forking.

For example, if an enterprise contains three end devices with the following AORs:

tel: +18041774568

sip: +18041774568@mydomain.com

Sip: jack@mydomain.com

All of the above AoRs are grouped under an AoR Group and enabled for call forking. When there is an incoming call to any one of the AoRs, the call is forked to all the AoRs in this group. To support call forking feature, the aorGroupProfile parameter is added to profiles configuration.

The SBC supports following timers related to SIP forking:

• Delay Before Ringing
• Answer Too Soon
• Wait for Answer