AudioCodes Mediant 500 MSBR, User Manual

Page: 634 / 1248

User's Manual 634 Document #: LTRT-10375
Mediant 500 MSBR
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).
Note:
•
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.
32.4.2 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):
1. Unique Contact generated by the device and sent in the initial registration request to
the serving proxy.
2. AOR. The AOR is originally obtained from the incoming REGISTER request and must
either match both user part and host part of the Request-URI, or only user part.
3. Contact. The Contact is originally obtained from the incoming REGISTER request.
If registrations are destined to the database (using the above rules), the device does not
attempt to find a database match, but instead replies with a SIP 200 OK (used for
Survivability). Once a match is found, the request is routed either to the contact received in
the initial registration or (if the device identifies that the user agent is behind a NAT) to the
source IP address of the initial registration.
You can configure (using the SBCDBRoutingSearchMode parameter) for which part of the
destination Request-URI in the INVITE message the device must search in the registration
database:

Only by entire Request-URI (user@host), for example, "4709@joe.company.com".

By entire Request-URI, but if not found, by the user part of the Request-URI, for
example, "4709".
When an incoming INVITE is received for routing to a user and the user is located in the
registration database, the device sends the call to the user's corresponding contact
address specified in the database.