General Registration Request Processing - AudioCodes Mediant 800 User Manual

Gateways & session border controllers
Hide thumbs Also See for Mediant 800:
Table of Contents

Advertisement

CHAPTER 30    SBC Overview
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.
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).
For
more
information,
Mediant 800 Gateway & E-SBC | User's Manual
see
the
description
- 748 -
of
the
[SBCURICom-

Hide quick links:

Advertisement

Table of Contents
loading

This manual is also suitable for:

E-sbc

Table of Contents