AudioCodes Mediant 3000, User Manual

Page: 407 / 872

Version 6.6 407 Mediant 3000
User's Manual 28. SBC Overview
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.
28.3.1 Initial Registration Request Processing
Registration requests have different processing policies than other SIP methods:
1. Determining source and destination URL's:
•
The source URL is obtained from the To header
•
The destination URL is obtained from the Request URI
2. Classification: The REGISTER classification process is the same as the general
classification process (described in previous sections). The source IP Group must be
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 IP-to-IP 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 is a User-type IP Group, 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 IP-to-IP 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, SBCProxyRegistrationTime, and
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).
28.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