SIP subscribe notify publish forwarding

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(Configuring)
 
(3 intermediate revisions by one user not shown)
Line 1: Line 1:
TSBC can forward SIP Subscribe, Notify and Publish messages between users and registrars (PBX).<br/>
+
ProSBC/FreeSBC can forward SIP Subscribe, Notify and Publish messages between users and registrars (PBX).<br/>
Forwarding of these messages follow the same rules as forwarding of [[Sip_registration_forwarding|SIP registration]].
+
Forwarding of these messages follows the same rules as forwarding of [[Sip_registration_forwarding|SIP registration]].
  
 
== SIP Subscribe overview ==
 
== SIP Subscribe overview ==
Line 8: Line 8:
 
* Conference
 
* Conference
  
Each user's device can register to various packages, then receive notifications for each of these package (independently).<br/>
+
Each user's device can register to various packages, then receive notifications for each of these packages (independently).<br/>
  
  
 
== SIP Subscribe/Publish forwarding ==
 
== SIP Subscribe/Publish forwarding ==
TSBC will forward SUBSCRIBE or PUBLISH requests from users to Registrar (PBX)
+
ProSBC/FreeSBC will forward SUBSCRIBE or PUBLISH requests from users to Registrar (PBX)
  
 
[[Image:subscribe_request_overview.png|700px]]<br/>
 
[[Image:subscribe_request_overview.png|700px]]<br/>
Line 19: Line 19:
  
 
== SIP Notify forwarding ==
 
== SIP Notify forwarding ==
TSBC will forward NOTIFY requests from Registrar (PBX) back to users.
+
ProSBC/FreeSBC will forward NOTIFY requests from Registrar (PBX) back to users.
  
 
[[Image:notify_request_overview.png|700px]]<br/>
 
[[Image:notify_request_overview.png|700px]]<br/>
Line 25: Line 25:
  
  
== Topology hiding (contact remapping) ==
+
== Contact remapping ==
TSBC will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":
+
When forwarding a SIP Subscribe message from a user to the registrar, ProSBC/FreeSBC will remap the contact to make itself the contact.
* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.
+
This way, the Registrar will send response messages and Notify events through ProSBC/FreeSBC, and thus make sure to "hide" private network topology from users (avoid messages being sent directly from registrar to users).
* Registrars/PBX addresses are hidden from the users by the TSBC (multiple registrars can be used for redundancy, and/or per domain name)
+
 
* Multiple users with the same name but from different domains are remapped using "aliases" so they still can be distinguished after going through TSBC
+
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:subscribe_topology_hiding.png|700px]]
 
[[Image:subscribe_topology_hiding.png|700px]]
  
 
== SIP authorization ==
 
== SIP authorization ==
SIP authorization requests (401/407 Unauthorized) are forwarded from Registrar to users, allowing users to send request again with appropriate credentials.<br/>
+
SIP authorization requests (401/407 Unauthorized) are forwarded from Registrar to users, allowing users to send the request again with appropriate credentials.<br/>
TSBC does not perform authorization by itself, only forwards between users and registrars.
+
ProSBC/FreeSBC does not perform authorization by itself, only forwards between users and registrars.
  
 
== NAT traversal ==
 
== NAT traversal ==
*The TSBC handles SIP Subscribe NAT traversal to allow interaction between SIP User Agents from public and private networks.
+
*ProSBC/FreeSBC handles SIP Subscribe NAT traversal to allow interaction between SIP User Agents from public and private networks.
**TSBC detects the actual IP from which users are sending messages, so responses and Notify messages can be forwarded properly, even in case users are unaware that they are behind a NAT
+
**ProSBC/FreeSBC detects the actual IP from which users are sending messages, so responses and Notify messages can be forwarded properly, even in case users are unaware that they are behind a NAT
  
 
== Configuring ==
 
== Configuring ==

Latest revision as of 04:13, 25 January 2021

ProSBC/FreeSBC can forward SIP Subscribe, Notify and Publish messages between users and registrars (PBX).
Forwarding of these messages follows the same rules as forwarding of SIP registration.

Contents

SIP Subscribe overview

The SIP SUBSCRIBE method allows users to subscribe to various services, and get notified of events related to these services. Typical services (packages) that phones will register to are:

  • Voice mail
  • Presence
  • Conference

Each user's device can register to various packages, then receive notifications for each of these packages (independently).


SIP Subscribe/Publish forwarding

ProSBC/FreeSBC will forward SUBSCRIBE or PUBLISH requests from users to Registrar (PBX)

Subscribe request overview.png
Subscribe response overview.png


SIP Notify forwarding

ProSBC/FreeSBC will forward NOTIFY requests from Registrar (PBX) back to users.

Notify request overview.png
Notify response overview.png


Contact remapping

When forwarding a SIP Subscribe 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 and Notify events 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.

Subscribe topology hiding.png

SIP authorization

SIP authorization requests (401/407 Unauthorized) are forwarded from Registrar to users, allowing users to send the request again with appropriate credentials.
ProSBC/FreeSBC does not perform authorization by itself, only forwards between users and registrars.

NAT traversal

  • ProSBC/FreeSBC handles SIP Subscribe NAT traversal to allow interaction between SIP User Agents from public and private networks.
    • ProSBC/FreeSBC detects the actual IP from which users are sending messages, so responses and Notify messages can be forwarded properly, even in case users are unaware that they are behind a NAT

Configuring

SIP Subscribe/Publish/Notify forwarding is automatically available when configuring SIP Domain for SIP Registration forwarding:

References

Personal tools