CHAPTER 28 Advanced SBC Features
Mediant 4000 SBC | User's Manual
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
Configuring SBC IP-to-IP Routing Rules
.
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:[email protected]</alias>
<alias>sip:[email protected]</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:
- 612 -
Summary of Contents for Mediant 4000 SBC
Page 1: ...User s Manual AudioCodes Series of Session Border Controllers SBC Mediant 4000 SBC Version 7 2...
Page 40: ...Part I Getting Started with Initial Connectivity...
Page 48: ...Part II Management Tools...
Page 113: ...Part III General System Settings...
Page 118: ...Part IV General VoIP Configuration...
Page 525: ...Part V Session Border Controller Application...
Page 654: ...Part VI Cloud Resilience Package...
Page 663: ...Part VII High Availability System...
Page 685: ...Part VIII Maintenance...
Page 759: ...Part IX Status Performance Monitoring and Reporting...
Page 844: ...Part X Diagnostics...
Page 888: ...Part XI Appendix...