Sip registration forwarding

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(Adding more information on how to control dynamic vs static routes)
 
(28 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
TSBC registration forwarding feature allows to control the registration requests flow between SIP User Agents and registrars. It allows adaptation of SIP register messages between SIP User Agents and registrars. It keeps information about SIP User Agent contacts and allows routing of SIP calls base on registration information.
+
== SIP Registration forwarding overview ==
 +
ProSBC/FreeSBC 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 [[SIP_subscribe_notify_publish_forwarding|SIP Subscribe/Publish/Notify forwarding]] 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.
  
−
== Protection ==
+
[[Image:registration_forwarding_overview.png|700px]]
−
*TSBC protects registrar from overloading of SIP User Agents register requests using different strategies (i.e. Firewall, Rate Adaptation, SIP Header Manipulation, Etc.).
+
  
 
== Forwarding Modes ==
 
== Forwarding Modes ==
−
*The TSBC always modifies the contact URI in SIP register requests to remain on the path between SIP User Agents and registrars.
+
*ProSBC/FreeSBC always modifies the contact URI in SIP register requests to remain on the path between SIP User Agents and registrars.
−
*The TSBC supports two different SIP registration forwarding modes (i.e. "Contact Remapping" or "Contact Passthrough").
+
*ProSBC/FreeSBC supports two different SIP registration forwarding modes (i.e. "Contact Remapping" or "Contact Passthrough").
−
*The "Contact Passthrough" forwarding mode makes contact username portion of the contact URI in SIP register requests to pass through unchanged.
+
*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 contact username portion of the contact URI in SIP register requests and make it unique.
+
*The "Contact Remapping" forwarding mode modifies the contact username portion of the Contact URI in SIP register requests and make it unique.
  
−
== Registrar Selection Mode ==
+
== Registrar Selection Mode (registration redundancy) ==
−
*The TSBC supports Active/Standby registrar selection mode. The active registrar is the one with status up and the lowest priority (automatic fallback).
+
*ProSBC/FreeSBC supports Active/Standby registrar selection mode. Users' registration requests are forwarded to the available registrar with the highest priority.
 +
[[Image:multiple_registrars.png]]
 +
 
 +
== Protection ==
 +
*ProSBC/FreeSBC protects the registrar(s) against excessive SIP User Agents register requests using different strategies (i.e. Firewall, Rate Adaptation, SIP Header Manipulation, Etc.).
 +
 
 +
== Contact remapping ==
 +
When forwarding a SIP Register message from a user to the registrar, ProSBC/FreeSBC will remap the contact to make itself the contact.
 +
This way, the Registrar will send response messages through ProSBC/FreeSBC, 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/FreeSBC 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.
 +
 +
[[Image:registration_topology_hiding.png|700px]]
  
 
== NAT traversal ==
 
== NAT traversal ==
−
*The TSBC handles SIP Calls NAT traversal then allows interaction between SIP User Agents from public and private networks.
+
*ProSBC/FreeSBC handles SIP Calls NAT traversal to allow interaction between SIP User Agents from public and private networks.
 +
**FreeSBC 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.
 
*It supports SIP register requests "Rate Adaptation" between SIP User Agents and registrar.
−
*Because refreshing requests are not always sent to registrar, "Rate adaptation" feature reduces SIP register requests sent to registrar. The "Rate Adaptation" feature is also useful to keep firewall ports open.
+
*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.
  
−
== SIP Calls routing ==
+
== SIP Calls routing per registered user ==
−
*The TSBC keeps SIP User Agents contacts information. This information serves on SIP calls routing when a SIP User Agent is trying to reach a registered users. It could be used also to accept calls from registered users only.
+
*ProSBC/FreeSBCkeeps 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.
  
 
=== Registered users and routing scripts ===
 
=== Registered users and routing scripts ===
−
In routing scripts, "dynamic" routes will be automatically created when a call is trying to reach a registered user.
+
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.<br/>
−
* These "dynamic" routes will use the outbound NAP that the registered user had registered from
+
When a user has registered multiple contacts (devices), they will be called one by one in a [[Route_retry|Route retry]] manner.
−
* These "dynamic" routes will add to any "static" routes that also match the incoming call (if any)
+
  
−
==== Priority of dynamic routes ====
+
[[Image:registered_users_call_routing_direct.png|400px]]
−
When "priority_and_weight_load_balancer" routing script is used, ordering of dynamic vs. static routes can be controlled:
+
 
−
* Dynamic routes will inherit the priority of the outbound (remapped) NAP that the targeted registered user was registered from
+
ProSBC/FreeSBC routes can also be organized so calls always go through the Registrar/PBX before being forwarded to the called user.
−
* All matching routes (static and dynamic) will be ordered by priority
+
 
−
* Some static routes may have higher priority than dynamic routes, others lower priority
+
[[Image:registered_users_call_routing_through_pbx.png|700px]]
−
* The option :max_priority_delta can be used to get rid of all route with lower priority.
+
 
−
** This can be used to keep only dynamic routes in some cases, for example if static routes have much lower priority than dynamic routes
+
Example:
−
** This can be used to keep only static routes in other cases, for example when incoming calls are from a specific NAP which matches a very high priority route
+
 
 +
[[File:registered_users_route.png]]
 +
 
 +
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).
  
 
== Configuration ==
 
== Configuration ==
Line 39: Line 63:
 
{| cellpadding="5" border="1" class="wikitable"
 
{| cellpadding="5" border="1" class="wikitable"
 
|-
 
|-
−
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | FreeSBC
+
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | ProSBC/FreeSBC
 
|-
 
|-
 
| valign="top" |  
 
| valign="top" |  
 
*[[Toolpack:Creating_a_SIP_Domain_SBC_A|3.0 Creating a SIP Domain]]
 
*[[Toolpack:Creating_a_SIP_Domain_SBC_A|3.0 Creating a SIP Domain]]
 +
*[[Configuring SIP Registration for Open NAP|3.0 Configuring SIP Registration for Open NAP]]
 +
*[[Configuring SIP Registration for regular NAP|3.0 Configuring SIP Registration for regular NAP]]
 
|}
 
|}
 +
 +
== References ==
 +
[[SIP_Registration|SIP Registration]]

Latest revision as of 04:11, 25 January 2021

Contents

SIP Registration forwarding overview

ProSBC/FreeSBC 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 SIP Subscribe/Publish/Notify forwarding 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.

Registration forwarding overview.png

Forwarding Modes

  • ProSBC/FreeSBC always modifies the contact URI in SIP register requests to remain on the path between SIP User Agents and registrars.
  • ProSBC/FreeSBC 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.

Registrar Selection Mode (registration redundancy)

  • ProSBC/FreeSBC supports Active/Standby registrar selection mode. Users' registration requests are forwarded to the available registrar with the highest priority.

Multiple registrars.png

Protection

  • ProSBC/FreeSBC protects the registrar(s) against excessive SIP User Agents register requests using different strategies (i.e. Firewall, Rate Adaptation, SIP Header Manipulation, Etc.).

Contact remapping

When forwarding a SIP Register message from a user to the registrar, ProSBC/FreeSBC will remap the contact to make itself the contact. This way, the Registrar will send response messages through ProSBC/FreeSBC, 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/FreeSBC 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.

Registration topology hiding.png

NAT traversal

  • ProSBC/FreeSBC handles SIP Calls NAT traversal to allow interaction between SIP User Agents from public and private networks.
    • FreeSBC 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.

SIP Calls routing per registered user

  • ProSBC/FreeSBCkeeps 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.

Registered users and routing scripts

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 Route retry manner.

Registered users call routing direct.png

ProSBC/FreeSBC routes can also be organized so calls always go through the Registrar/PBX before being forwarded to the called user.

Registered users call routing through pbx.png

Example:

Registered users route.png

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).

Configuration

ProSBC/FreeSBC

References

SIP Registration

Retrieved from "https://docs.telcobridges.com/mediawiki/index.php?title=Sip_registration_forwarding&oldid=29718"
Personal tools