Page History

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

Any out of dialog request terminating to the UA may be forked by the registrar or the AS.

The

Forking Behavior

This section describes the transaction matching logic used by

the

• 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

The

• 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

• 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

Spacevars
0 product

 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.

Note

Looped Request

The

Spacevars
0 product

 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

• Spacevars
  0 product

   IP address and a branch parameter value indicating that the previous Request-URI is same as received ingress Request-URI.

Downstream Forking

The

• 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

The following

• 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

• 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

• If the

  Spacevars
  0 product

   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

  Spacevars
  0 product

   does not change the early media on ingress leg. For any subsequent changes in an active early media on egress peer, the

  Spacevars
  0 product

   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

  Spacevars
  0 product

   forces the call to transcode even though pass-through is possible.
• Once a call becomes stable, the

  Spacevars
  0 product

   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

  Spacevars
  0 product

   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

  Spacevars
  0 product

   gracefully terminates the call if a final answer is received on an early dialog for which transcoding is not supported.
• The

  Spacevars
  0 product

   does not trigger this feature if the

  Spacevars
  0 product

   is configured for "Down Stream Forking" and to accept the First Provisional Response.

Application Layer Forking