SIP subscribe notify publish forwarding - Revision history

Serdar Civici at 10:17, 3 March 2022

2022-03-03T10:17:57Z

← Older revision		Revision as of 06:17, 3 March 2022
Line 1:		Line 1:
			{{DISPLAYTITLE:SIP subscribe notify publish forwarding}}
	ProSBC/FreeSBC 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 follows 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]].

Serdar Civici at 09:13, 25 January 2021

2021-01-25T09:13:22Z

← Older revision		Revision as of 05:13, 25 January 2021
Line 1:		Line 1:
	FreeSBC 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 ==
	FreeSBC 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 ==
	FreeSBC 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 26:		Line 26:

	== Contact remapping ==		== Contact remapping ==
	When forwarding a SIP Subscribe message from a user to the registrar, FreeSBC will remap the contact to make itself the contact.		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 FreeSBC, and thus make sure to "hide" private network topology from users (avoid messages being sent directly from registrar to users).		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, 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.		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/>
	FreeSBC 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 ==
	*FreeSBC 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.
	**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		**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 ==

Abrassard: Updated doc to avoid referring to "Topology hiding"

2018-07-05T18:01:20Z

Updated doc to avoid referring to "Topology hiding"

← Older revision		Revision as of 14:01, 5 July 2018
Line 25:		Line 25:


	== ~~Topology hiding (contact~~ remapping) ==		== Contact remapping ==
	FreeSBC 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, FreeSBC will remap the contact to make itself the contact.
	* Users always send ~~SUBSCRIBE requests to~~ FreeSBC, and ~~receive NOTIFY~~ from ~~FreeSBC, even if there are multiple Registrars behind~~.		This way, the Registrar will send response messages and Notify events through 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~~ FreeSBC ~~(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 FreeSBC~~		Because the contact's domain is being remapped, 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]]

Abrassard: Changing TSBC to FreeSBC

2018-06-20T18:23:23Z

Changing TSBC to FreeSBC

Abrassard at 14:47, 18 June 2018

2018-06-18T14:47:34Z

← Older revision		Revision as of 10:47, 18 June 2018
Line 28:		Line 28:
	TSBC will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":		TSBC will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":
	* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.		* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.
	* Registrars/PBX addresses are hidden from the users by ~~the~~ TSBC (multiple registrars can be used for redundancy, and/or per domain name)		* Registrars/PBX addresses are hidden from the users by 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		* Multiple users with the same name but from different domains are remapped using "aliases" so they still can be distinguished after going through TSBC

Line 38:		Line 38:

	== NAT traversal ==		== NAT traversal ==
	*~~The~~ TSBC handles SIP Subscribe NAT traversal to allow interaction between SIP User Agents from public and private networks.		*TSBC 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		**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

Abrassard: /* Configuring */

2018-06-18T12:40:16Z

Configuring

← Older revision		Revision as of 08:40, 18 June 2018
Line 43:		Line 43:
	== Configuring ==		== Configuring ==
	SIP Subscribe/Publish/Notify forwarding is automatically available when configuring SIP Domain for [[Sip_registration_forwarding\|SIP Registration forwarding]]:		SIP Subscribe/Publish/Notify forwarding is automatically available when configuring SIP Domain for [[Sip_registration_forwarding\|SIP Registration forwarding]]:
	* [[Creating_a_SIP_Domain_SBC_A\|Creating a SIP domain]]		* [[Toolpack:Creating_a_SIP_Domain_SBC_A\|Creating a SIP domain]]

	== References ==		== References ==
	* [https://andrewjprokop.wordpress.com/2015/03/11/a-deep-dive-into-sip-subscriptions/ Understanding SIP Subscribe]		* [https://andrewjprokop.wordpress.com/2015/03/11/a-deep-dive-into-sip-subscriptions/ Understanding SIP Subscribe]
	* [https://www.iana.org/assignments/sip-events/sip-events.xhtml IANA SIP Event types]		* [https://www.iana.org/assignments/sip-events/sip-events.xhtml IANA SIP Event types]

Abrassard: /* NAT traversal */

2018-06-18T12:39:41Z

NAT traversal

← Older revision		Revision as of 08:39, 18 June 2018
Line 41:		Line 41:
	**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		**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

			== Configuring ==
			SIP Subscribe/Publish/Notify forwarding is automatically available when configuring SIP Domain for [[Sip_registration_forwarding\|SIP Registration forwarding]]:
			* [[Creating_a_SIP_Domain_SBC_A\|Creating a SIP domain]]

	== References ==		== References ==
	* [https://andrewjprokop.wordpress.com/2015/03/11/a-deep-dive-into-sip-subscriptions/ Understanding SIP Subscribe]		* [https://andrewjprokop.wordpress.com/2015/03/11/a-deep-dive-into-sip-subscriptions/ Understanding SIP Subscribe]
	* [https://www.iana.org/assignments/sip-events/sip-events.xhtml IANA SIP Event types]		* [https://www.iana.org/assignments/sip-events/sip-events.xhtml IANA SIP Event types]

Abrassard: moved SIP subscribe notify publish to SIP subscribe notify publish forwarding

2018-06-18T12:36:44Z

moved SIP subscribe notify publish to SIP subscribe notify publish forwarding

← Older revision	Revision as of 08:36, 18 June 2018
(No difference)

Abrassard: /* Topology hiding (contact remapping) */

2018-06-18T12:33:14Z

Topology hiding (contact remapping)

← Older revision		Revision as of 08:33, 18 June 2018
Line 28:		Line 28:
	TSBC will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":		TSBC will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":
	* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.		* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.
	* Registrars/PBX addresses are hidden by the TSBC (multiple registrars can be used for redundancy, and/or per domain name)		* 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		* Multiple users with the same name but from different domains are remapped using "aliases" so they still can be distinguished after going through TSBC

Abrassard: /* Topology hiding (contact remapping) */

2018-06-18T12:31:26Z

Topology hiding (contact remapping)

← Older revision		Revision as of 08:31, 18 June 2018
Line 29:		Line 29:
	* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.		* Users always send SUBSCRIBE requests to TSBC, and receive NOTIFY from TSBC, even if there are multiple Registrars behind.
	* Registrars/PBX addresses are hidden by the TSBC (multiple registrars can be used for redundancy, and/or per domain name)		* Registrars/PBX addresses are hidden 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

	[[Image:subscribe_topology_hiding.png\|700px]]		[[Image:subscribe_topology_hiding.png\|700px]]

← Older revision		Revision as of 14:23, 20 June 2018
Line 1:		Line 1:
	~~TSBC~~ can forward SIP Subscribe, Notify and Publish messages between users and registrars (PBX).<br/>		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 follow the same rules as forwarding of [[Sip_registration_forwarding\|SIP registration]].

Line 12:		Line 12:

	== SIP Subscribe/Publish forwarding ==		== SIP Subscribe/Publish forwarding ==
	~~TSBC~~ will forward SUBSCRIBE or PUBLISH requests from users to Registrar (PBX)		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.		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 26:		Line 26:

	== Topology hiding (contact remapping) ==		== Topology hiding (contact remapping) ==
	~~TSBC~~ will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":		FreeSBC will remap SIP headers (from/to/contact/via/route...) while forwarding messages between users Registrars/PBX to perform "topology hiding":
	* Users always send SUBSCRIBE requests to ~~TSBC~~, and receive NOTIFY from ~~TSBC~~, even if there are multiple Registrars behind.		* Users always send SUBSCRIBE requests to FreeSBC, and receive NOTIFY from FreeSBC, even if there are multiple Registrars behind.
	* Registrars/PBX addresses are hidden from the users by ~~TSBC~~ (multiple registrars can be used for redundancy, and/or per domain name)		* Registrars/PBX addresses are hidden from the users by FreeSBC (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~~		* Multiple users with the same name but from different domains are remapped using "aliases" so they still can be distinguished after going through FreeSBC

	[[Image:subscribe_topology_hiding.png\|700px]]		[[Image:subscribe_topology_hiding.png\|700px]]
Line 35:		Line 35:
	== 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 request again with appropriate credentials.<br/>
	~~TSBC~~ does not perform authorization by itself, only forwards between users and registrars.		FreeSBC does not perform authorization by itself, only forwards between users and registrars.

	== NAT traversal ==		== NAT traversal ==
	*~~TSBC~~ handles SIP Subscribe NAT traversal to allow interaction between SIP User Agents from public and private networks.		*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		**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 ==