Classification And Routing Of Registered Users - AudioCodes E-SBC User Manual

CHAPTER 30 SBC Overview
■ If registration succeeds (replied with 200 OK by the destination server), the device adds a
record to its' registration database, which identifies the specific contact of the specific user
(AOR). The device uses this record to route subsequent SIP requests to the specific user (in
normal or survivability modes).
■ The records in the device's registration database include the Contact header. The device adds
every REGISTER request to the registration database before manipulation, allowing correct
user identification in the Classification process for the next received request.
■ You can configure Call Admission Control (CAC) rules for incoming and outgoing REGISTER
messages. For example, you can limit REGISTER requests from a specific IP Group or SRD.
Note that this applies only to concurrent REGISTER dialogs and not concurrent registrations in
the device's registration database.
The device provides a dynamic registration database that it updates according to registration
requests traversing it. Each database entry for a user represents a binding between an AOR
(obtained from the SIP To header), optional additional AORs, and one or more contacts (obtained
from the SIP Contact headers). Database bindings are added upon successful registration
responses from the proxy server (SIP 200 OK). The device removes database bindings 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 UA did not send a refresh
registration request).
●
●
●
●

Classification and Routing of Registered Users

The device can classify incoming SIP dialog requests (e.g., INVITE) from registered users to an IP
Group, by searching for the sender's details in the registration database. The device uses the AOR
from the From header and the URL in the Contact header of the request to locate a matching
registration binding. The found registration binding contains information regarding the registered
user, including the IP Group to which it belongs. (Upon initial registration, the Classification table is
used to classify the user to a User-type IP Group and this information is then added with the user in
the registration database.)
The destination of a dialog request can be a registered user and the device thus uses its registration
database to route the call. This can be achieved by various ways such as configuring a rule in the
IP- to- IP Routing table where the destination is a User- type IP Group or any matching user
registered in the database ('Destination Type' is configured to All Users). The device searches the
registration database for a user that matches the incoming Request-URI (listed in chronological
order):
■ Unique Contact generated by the device and sent in the initial registration request to the
serving proxy.
■ AOR. The AOR is originally obtained from the incoming REGISTER request and must either
match both user part and host part (user@host) of the Request-URI, or only user part.
■ Contact. The Contact is originally obtained from the incoming REGISTER request.
The same contact cannot belong to more than one AOR.
Contacts with identical URIs and different ports and transport types are not
supported (same key is created).
Multiple contacts in a single REGISTER message is not supported.
One database is shared between all User-type IP Groups.
Mediant 1000 Gateway & E-SBC | User's Manual
- 726 -