AudioCodes Mediant 3000, User Manual

Page: 408 / 872

User's Manual 408 Document #: LTRT-89729
Mediant 3000
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)
The database has the following limitations:

Maximum of five contacts per AOR

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 is not supported

One database is shared between all User-type IP Groups
28.3.3 Routing using Internal Database
Typically, routing using the database is applicable to all method types other than
registrations. To route to a registered user (using the internal dynamic database), the
following steps must be taken:
1. An IP-to-IP Routing rule with the desired input parameters (matching characteristics)
and the destination type as IP Group (operation rule).
2. The destination IP Group must be of type User.
3. To find a match for these specific rules, the device attempts to locate a match
between the incoming Request-URI and (according to the description order):
a. Unique contact - the Contact generated by the SBC and sent in the initial
registration request to the serving proxy
b. Registered AOR - the AOR of the incoming REGISTER request
c. Registered contact - the Contact of 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 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.
28.3.4 Registration Refreshes
Registration refreshes are incoming REGISTER requests that are associated with a
specific registered user. The association is performed by searching the internal registration
database. These refreshes are routed to the serving proxy only if the serving proxy Expires
time is about to expire; otherwise, the device responds with a 200 OK without routing the
REGISTER. Each such refreshes also refresh the internal timer time set on the device for
this specific registration.
28.3.5 Notification of Expired User Registration to SIP Proxy / Registrar
The device automatically notifies SIP Proxy / Registrar servers of users registered in the
device's database whose registration timeout has expired. When a user's registration timer
expires, the device removes the user record from its Registration database and sends an
unregister notification (REGISTER message with the Expires header set to 0) to the
Proxy/Registrar.