SIP registration forwarding
Last updated
Was this helpful?
Last updated
Was this helpful?
ProSBC registration forwarding feature allows controlling the registration requests flow between SIP User Agents and registrars.
It allows adaptation of SIP register messages between SIP User Agents and registrars.
It allows adaptation of messages between SIP User Agents and registrars.
It keeps the information about SIP User Agent contacts to allow routing of SIP calls base on registration information.
ProSBC always modifies the contact URI in SIP register requests to remain on the path between SIP User Agents and registrars.
ProSBC supports two different SIP registration forwarding modes (i.e. "Contact Remapping" or "Contact Passthrough").
The "Contact Passthrough" forwarding mode makes the contact username portion of the Contact URI in SIP register requests to pass through unchanged.
The "Contact Remapping" forwarding mode modifies the contact username portion of the Contact URI in SIP register requests and make it unique.
ProSBC supports Active/Standby registrar selection mode. Users' registration requests are forwarded to the available registrar with the highest priority.
ProSBC protects the registrar(s) against excessive SIP User Agents register requests using different strategies (i.e. Firewall, Rate Adaptation, SIP Header Manipulation, Etc.).
When forwarding a SIP Register message from a user to the registrar, ProSBC will remap the contact to make itself the contact. This way, the Registrar will send response messages through ProSBC, and thus make sure to "hide" private network topology from users (avoid messages being sent directly from registrar to users).
Because the contact's domain is being remapped, ProSBC will also remap the contact's user name to make sure there is not user name conflict between two domains that would have the same user name.
ProSBC handles SIP Calls NAT traversal to allow interaction between SIP User Agents from public and private networks.
SBC detects the actual IP from which users have registered, so response messages and SIP Invite requests can be forwarded properly, even in case users are unaware that they are behind a NAT
It supports SIP register requests "Rate Adaptation" between SIP User Agents and registrar.
Because refreshing requests are not always sent to the registrar, the "Rate adaptation" feature reduces SIP register requests sent to the registrar. The "Rate Adaptation" feature is also useful to keep firewall ports open.
Since SIP User Agents may be behind firewalls, it may be necessary to force a quick polling of the registered phone to make sure the port forwarding for the SIP calls stay active.
To do so, you can use the configuration Poll Registered Users and select the Registered Users Polling Interval. This interval must be lower than the Firewall's timeouts. Since this may be difficult to find, our experience shows that a polling interval of 30 seconds will work in all cases we have seen.
ProSBC keeps SIP User Agents' contacts information. This information serves on SIP calls routing when a SIP User Agent is trying to reach a registered user. It could be used also to accept calls from registered users only.
ProSBC routes can also be organized so calls always go through the Registrar/PBX before being forwarded to the called user.
Example:
In this example, there are 2 routes:
ROUTE_FROM_OPEN_NAP will match all incoming calls received from NAP_OPEN, and forward them to NAP_PBX
ROUTE_FROM_PBX will match all incoming calls received from NAP_PBX, and forward them by the registered user (will forward to whatever NAP the target user has registered from)
Here, if "alice" calls "bob" from NAP_OPEN, the call will be forwarded to the PBX. Then the PBX may route back the call to the SBC, which will then forward to "bob" on NAP_OPEN. In other words, all calls from NAP_OPEN will go through the PBX.
In this example, the routes are exclusive (only one will match for a given incoming call). But there could be multiple matching routes. In this case, routes will be ordered by priority (whether they route by registered user, or to a specific outbound NAP).
Registered users can be reached by creating static routes without a specific "outbound NAP". These routes, instead of forwarding calls to a specific NAP, will dynamically choose the outbound NAP by matching the target registered user. When a user has registered multiple contacts (devices), they will be called one by one in a manner.
