AudioCodes Mediant 4000 SBC, Руководство пользователя

Страница: 534 / 1037

CHAPTER 22 SBC Overview
Mediant 4000 SBC | User's Manual
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.
If the Request-URI contains the "tel:" URI or "user=phone" parameter, the device
searches only for the user part.
You can also configure (using the [SBCURIComparisonExcludedParams] parameter) which URI
parameters are excluded when the device compares the URIs of two incoming dialog-initiating SIP
requests (e.g., INVITEs) to determine if they were sent from a user that is registered in the device's
registration database. For example, you can configure the parameter to exclude ports from the
comparison.
For more information, see the description of the [SBCURICom-
parisonExcludedParams] parameter.
General Registration Request Processing
The device's general handling of registration requests (REGISTER messages) for unregistered
users is as follows:
■ The device routes REGISTER requests according to the IP-to-IP Routing table. If the
destination is a User-type IP Group, the device does not forward the registration; instead, it
accepts (replies with a SIP 200 OK response) or rejects (replies with a SIP 4xx) the request
according to the user's IP Group configuration.
■ Alternative routing can be configured for REGISTER requests, in the IP-to-IP Routing table.
■ By default, the Expires header has the same value in incoming and outgoing REGISTER
messages. However, you can modify the Expires value using the following parameters:
SBCUserRegistrationTime, SBCProxyRegistrationTime, SBCRandomizeExpires, and
SBCSurvivabilityRegistrationTime. You can also modify the Expires value of REGISTER
requests received from users located behind NAT, using the IP Profile parameters IpProfile_
SBCUserBehindUdpNATRegistrationTime and IpProfile_SBCUser-
BehindTcpNATRegistrationTime.
■ By default, the Contact header in outgoing REGISTER message is different than the Contact
header in the incoming REGISTER. The user part of the Contact is populated with a unique
contact generated by the device and associated with the specific registration. The IP address
in the host part is changed to the address of the device. Alternatively, the original user can be
retained in the Contact header and used in the outgoing REGISTER request (using the
SBCKeepContactUserinRegister parameter).
- 501 -