User's Manual 782 Document #: LTRT-10632
Mediant 800B Gateway & E-SBC
INVITE-initiating UA and disregards subsequently received 18x forking responses
(with or without SDP).
Sequential: The device forwards all 18x responses to the INVITE-initiating UA,
sequentially (one after another). If 18x arrives with an offer only, only the first offer is
forwarded to the INVITE-initiating UA.
To configure the call forking mode:
1. Open the SBC General Settings page (Setup menu > Signaling & Media tab > SBC
folder > SBC General Settings).
2. From the 'Forking Handling Mode' drop-down list (SBCForkingHandlingMode), select
the required mode:
3. Click Apply.
The device also supports media synchronization for call forking. If the active UA is the first
one to send the final response (e.g., 200 OK), the call is established and all other final
responses are acknowledged and a BYE is sent if needed. If another UA sends the first
final response, it is possible that the SDP answer that was forwarded to the INVITE-
initiating UA is irrelevant and thus, media synchronization is needed between the two UAs.
Media synchronization is done by sending a re-INVITE request immediately after the call is
established. The re-INVITE is sent without an SDP offer to the INVITE-initiating UA. This
causes the INVITE-initiating UA to send an offer which the device forwards to the UA that
confirmed the call. Media synchronization is enabled by the EnableSBCMediaSync
parameter.
38.5.3 Configuring Call Forking-based IP-to-IP Routing Rules
You can configure call forking routing rules in the IP-to-IP Routing table. This is done by
configuring multiple routing rules under a forking group. These rules send an incoming IP
call to multiple destinations of any type (e.g., IP Group or IP address). The device forks the
call by sending simultaneous INVITE messages to all the specified destinations. It handles
the multiple SIP dialogs until one of the calls is answered and then terminates the other
SIP dialogs. For more information, see 'Configuring SBC IP-to-IP Routing Rules' on page
709.
38.6 Call Survivability
This section describes various call survivability features supported by the SBC device.
38.6.1 Enabling Auto-Provisioning of Subscriber-Specific Information of
BroadWorks Server for Survivability
This feature enables SBC user registration for interoperability with BroadSoft BroadWorks
server to provide call survivability in case of connectivity failure with the BroadWorks
server, for example, due to a WAN failure. The feature enables local users to dial a local
extension (or any other configured alias) that identifies another local user, in survivability
mode.
In normal operation, when subscribers (such as IP phones) register with the BroadWorks
server through the device, the device includes the SIP Allow-Events header in the sent
REGISTER message. In response, the BroadWorks server sends the device a SIP 200 OK
containing an XML body with subscriber information such as extension number, phone
number, and URIs (aliases), as shown in the example below:
To Next Page
Loading...
