AudioCodes Mediant 500 E-SBC, User Manual

Page: 469 / 920

User's Manual 27. SBC Overview
Version 6.8 469 Mediant 500 E-SBC
27.9 Call Forking
This section describes various Call Forking features supported by the device.
27.9.1 Initiating SIP Call Forking
The SBC device supports call forking of an incoming call to multiple SBC users
(destinations). Call forking is supported by the device's capability of registering multiple SIP
client user phone contacts (mobile and fixed-line extensions) under the same Address of
Record (AOR) in its registration database. This feature can be implemented in the following
example scenarios:

An enterprise Help Desk, where incoming customer calls are simultaneously sent to
multiple customer service agent extensions.

An employee's phone devices, where the incoming call is simultaneously sent to
multiple devices (e.g., to the employee's office phone and mobile SIP phone).

An enterprise reception desk, where an incoming call is simultaneously sent to
multiple receptionists.
The device supports various modes of call forking. For example, in Parallel call forking
mode, the device sends the INVITE message simultaneously to all the users registered
under the same AOR, resulting in the ringing of all extensions; the first extension to pick up
the call receives the call, and all other extensions stop ringing. The Call Forking feature is
configured by creating a User-type IP Group and configuring the IP Group table's
parameter, 'SBC Client Forking Mode' (see ''Configuring IP Groups'' on page
263 ).
The device can also fork INVITE messages received for a Request-URI of a specific
contact (user), belonging to the destination IP Group User-type, registered in the database
to all other users located under the same AOR as the specific contact. This is configured
using the SBCSendInviteToAllContacts parameter.
27.9.2 SIP Forking Initiated by SIP Proxy Server
The device can handle SIP forking responses received from a proxy server in response to
an INVITE forwarded by the device from a UA. In other words, received responses with a
different SIP To header 'tag' parameter for the request forwarded by the device. This
occurs in scenarios, for example, where a proxy server forks the INVITE request to several
UAs, and therefore, the SBC device may receive several replies for a single request.
Forked SIP responses may result in a single SDP offer with two or more SDP answers
during call setup. The SBC handles this scenario by "hiding" the forked responses from the
INVITE-initiating UA. This is achieved by marking the UA that responded first to the INVITE
as the active UA, and only requests/responses from that UA are subsequently forwarded.
All other requests/responses from other UAs are handled by the SBC (SDP offers from
these users are answered with an 'inactive' media).
The SBC supports two forking modes, configured by the SBCForkingHandlingMode
parameter:

Latch On First - only the first received 18x response is forwarded to the INVITE
initiating UA, and disregards any subsequently received 18x forking responses (with or
without SDP).

Sequential - all 18x responses are forwarded to the INVITE initiating UA, one at a time
in a sequential manner. If 18x arrives with an offer only, only the first offer is forwarded
to the INVITE initiating UA.
The SBC 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, then it is possible that the SDP answer that was forwarded to the INVITE-
initiating UA is not relevant, and media synchronization is needed between the two UAs.
Media synchronization is done by sending a re-INVITE request immediately after the call is