In this section:
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.
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.
This section describes the transaction matching logic used by the SBC to determine if an ingress SIP request is one of the following:
Additionally, for the below matching logics, Request-URI comparison is accomplished as follows:
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:
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.
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:
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:
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:
The SBC, acting as B2BUA, exhibits following downstream forking behavior:
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:
The cut-through for Downstream Forking is defined based on:
While receiving SDP answers in 18x responses, the SBC gracefully handles 18x responses by:
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.
Since the answer received from the egress peer can have multiple codecs, IPSP flags "SendOnlyPreferredCodec" and/or "LockDownPreferredCodec" must be enabled on both ingress and egress trunk groups.
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 In external PSX, the flag The SBC supports following timers related to SIP forking: Native Call Forking does not support GW-GW scenarios.aorGroupProfile
parameter is added to profiles
configuration.Enable Call Forking
is used to enable or disable the call forking functionality. However, this flag is not available in the SBC (ERE). The SBC performs VOIP Subscriber dip to determine the AoR Group. If AoRs are found for the VOIP subscriber, the call is forked to different AoR devices.