SIP Forking Support

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. 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 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 sipTrunkGroup 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

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

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

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:

• SBC terminates forked dialogs on the egress call leg, shielding caller from signaling related to call forking.
• SBC supports 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.
• SBC honors the SDP answer received in 18x on the same dialog as active dialog.
• SBC honors the SDP answer received in 18x response on a different dialog than the active dialog.
• SBC uses UPDATE towards the caller to indicate the new offer received in a 18x.
• On receipt of a final response from the egress entity, SBC forwards the same on ingress leg.

When a downstream forking entity sends a 199 response code for a particular early dialog, 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:

• SBC accepts up to ten 18x responses for the same INVITE request having different to-tag values.
• SBC 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, SBC 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, SBC 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.

Downstream Forking provisional responses are defined as:

• 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.
• lastProvResponse—Last Reliable Provisional response. Cut through when the latest provisional response with SDP is received.

While receiving SDP answers in 18x responses, 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).