AudioCodes Mediant 500 E-SBC, User Manual

Page: 447 / 920

User's Manual 27. SBC Overview
Version 6.8 447 Mediant 500 E-SBC
27.3 User Registration
To allow registrations to traverse the SBC, the device must be configured with at least one
User-type IP Group. These IP Groups represent a group of user agents that share the
following characteristics:

Perform registrations and share the same serving proxy\registrar

Possess identical SIP and media behavior

Reside on the same Layer-3 network and are associated with the same SRD
Typically, the device is configured as the user agent's outbound proxy and the device is
configured (using the IP-to-IP Routing table) to route requests received from this IP Group
to the serving proxy and vice versa. Survivability can be achieved using the alternative
routing feature.
27.3.1 Initial Registration Request Processing
The device's handling of registration requests (REGISTER messages) are as follows:

The device obtains the source URL from the SIP To header and the destination URL
from the Request-URI.

The device's classification process for REGISTER requests is the same as for other
SIP messages. However, the REGISTER request must be received from
User-type IP
Groups only. If classification fails or the IP Group is not a User-type, the device rejects
the registration request.

The device's routing of REGISTER requests is done using the IP-to-IP Routing table.
If the destination is a User-type IP Group, the device does not forward the registration;
instead, it accepts (replies with a SIP 200 OK response) or rejects (SIP 4xx) the
request, according to the user's IP Group configuration.

If registration succeeds (replied with 200 OK by the IP PBX), the device adds a record
to its Users Registration database that identifies the specific contact of the specific
user (AOR). This record is used by the device to route subsequent requests to the
specific user (in normal or in survivability modes).

Alternative routing can be configured for REGISTER requests, in the IP-to-IP Routing
table.

The record in the device's database includes the SIP Contact header. Every
REGISTER request is added to the database before manipulation, allowing correct
user identification in the Classification process for the next received request.

Call Admission Control (CAC) can be configured for incoming and outgoing
REGISTER requests. For example, limiting REGISTER requests from a certain IP
Group/SRD. Note that this is only for concurrent register dialogs and not concurrent
registrations in the device's Users Registration database.

The device can retain the original value of the SIP Expires header received from the
user or proxy, in the outgoing REGISTER message. This feature also applies when
the device is in survivability mode (i.e., REGISTER requests cannot be forwarded to
the proxy and is terminated by the device). This is configured by the
SBCUserRegistrationTime, SBCProxyRegistrationTime, SBCRandomizeExpires, and
SBCSurvivabilityRegistrationTime parameters.

By default, the Contact header in the outgoing REGISTER is populated with a unique
contact generated by the device and associated with the specific registration.
Alternatively, the original user can be retained in the Contact header and used in the
outgoing REGISTER request (using the SBCKeepContactUserinRegister parameter).