Initial Registration Request Processing; Sbc Users Registration Database - AudioCodes Mediant 800B MSBR User Manual

Mediant 800B MSBR
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.

32.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 or change 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,
SBCSurvivabilityRegistrationTime, and SBCRandomizeExpires 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).

32.3.2 SBC Users Registration Database

The device manages a dynamic Users Registration database that is updated according to
registration requests that traverse it. Each database entry for a user represents a binding
between an AOR (obtained from the SIP To header) and one or more contact (obtained
from the SIP Contact headers). Database bindings are added upon successful registration
responses.
Database bindings are removed in the following cases:

Successful de-registration responses (REGISTER with Expires header that equals
zero).

Registration failure responses.
Version 6.8 505
32. SBC Overview
Mediant 800B MSBR