Configuring Call Forking-Based Ip-To-Ip Routing Rules; Call Survivability; Enabling Auto-Provisioning Of Subscriber-Specific Information Of Broadworks Server For Survivability - AudioCodes Mediant 4000 SBC User Manual

Session border controllers
Hide thumbs Also See for Mediant 4000 SBC:
Table of Contents

Advertisement

CHAPTER 28    Advanced SBC Features
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.

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

Call Survivability

This section describes various call survivability features supported by the SBC device.
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:
<?xml version="1.0" encoding="utf-8"?>
<BroadsoftDocument version="1.0" content="subscriberData">
<phoneNumbers>
<phoneNumber>2403645317</phoneNumber>
<phoneNumber>4482541321</phoneNumber>
</phoneNumbers>
<aliases>
<alias>sip:bob@broadsoft.com</alias>
<alias>sip:rhughes@broadsoft.com</alias>
</aliases>
<extensions>
<extension>5317</extension>
<extension>1321</extension>
</extensions>
</BroadSoftDocument>
The device forwards the 200 OK to the subscriber (without the XML body). The call flow is shown
below:
Configuring SBC IP-to-IP Routing
Rules.
- 612 -
Mediant 4000 SBC | User's Manual

Advertisement

Table of Contents
loading

Table of Contents