Internal Database - AudioCodes Mediant 3000 User Manual

of type USER. If classification fails or the source IP Group is not of type USER, the
registration is rejected.
3. Routing: The REGISTER routing is performed using the IP2IP Routing table:
•
The destination type can be an IP Group, specific IP address, Request-URI, or
ENUM query (can also use DNS queries).
•
If the destination IP Group is of type USER, then the registration is not be
forwarded. Instead, the device accepts (replies with 200 OK response) or rejects
(Reply with 4xx) the request according to the user group policy.
4. Internal registration database: If the source IP Group is of type User and registration
succeeds (replied with 200 OK by the IP-PBX), then the device adds a record to its
database that identified the specific contact of this specific user (AOR). This record is
used later to route requests to this specific user (either in normal or in survivability
modes).
5. Alternative Routing: Alternative routing can be configured in the IP2IP Routing table
for REGISTER requests.
6. Inbound Manipulation: The SBC record in the device's database includes the Contact
header. Every REGISTER request is added to the database before manipulation,
allowing correct user identification in the SBC Classification process for the next
received request.
7. Session Admission Control: Applies various limitations on incoming and outgoing
REGISTER requests. For example, limiting REGISTER requests from a certain IP
Group/SRD. Note that this limitation is only for concurrent register dialogs and not
concurrent registrations in the internal database.
8. 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" state (i.e., REGISTER requests cannot be forwarded to
the proxy and is terminated by the device). This is configured by the
SBCUserRegistrationTime,
SBCSurvivabilityRegistrationTime parameters.
9. By default, the Contact of the outgoing REGISTER is populated with a unique Contact
generated by the device and associated with this specific registration. Alternatively,
the original user can be retained in the Contact and used in the outgoing REGISTER
request (using the SBCKeepContactUserinRegister parameter).

19.1.3.2 Internal Database

The device manages a dynamic database that is updated according to registration
requests that traverse the SBC. Each database entry represents a binding between an
AOR and one or more contact. Database bindings are added upon successful registration
responses. For specific registrations, the AOR is obtained from the SIP To header and the
contact is taken from the SIP Contact header.
Database bindings are removed in the following cases:

Successful de-registration responses (REGISTER with Expires header that equals
zero)

Registration failure responses

Timeout of the Expires header value (in scenarios where the user agent did not send a
refresh registration request)
SIP User's Manual
SBCProxyRegistrationTime,
368
Mediant 3000
and
Document #: LTRT-89712