SIP Registration

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(→Configuration)
 
(20 intermediate revisions by 4 users not shown)
Line 6: Line 6:
 
[[Image:SIP Registration Process.jpg|400px]]
 
[[Image:SIP Registration Process.jpg|400px]]
  
−
Tmedia does not provide registrar functionality, therefore, a SIP client cannot register to a Tmedia. If a SIP clients communicate to another SIP clients (B2BUA) in point-to-point fashion and not through a SIP proxy, REGISTER is usually not required. In that case, the SIP clients are required to know the IP addresses or DNS of all the other clients they wish to communicate with.
+
Tmedia supports two modes for SIP Registration:
 +
* The Tmedia forwards per-user registration requests from users
 +
** [[Sip_registration_forwarding|Explanation of Tmedia's registration forwarding]]
 +
** [[Toolpack:Creating_a_SIP_Domain_SBC_A|Configuration of Tmedia's registration forwarding]]
 +
* The Tmedia registers itself to the SIP Proxy (per SIP NAP, as explained below in current page)
  
−
== Registration ==
+
== Registration per SIP NAP ==
−
The Tmedia supports to register a SIP [[NAP]] to a SIP proxy. Registration, can be used, for example, to authenticate the Tmedia Gateway IP address to a SIP provider proxy or SBC an allow the SIP traffic from the Tmedia to that SIP provider.
+
The Tmedia supports to register a SIP [[NAP]] to a SIP proxy. Registration, can be used, for example, to authenticate the Tmedia Gateway IP address to a SIP provider proxy or SBC and allow the SIP traffic from the Tmedia to that SIP provider.
−
 
+
* Registration is when Tmedia sends a SIP REGISTER to a Registrar, and gets a response which could be accepted (200 OK) or refused (4xx reason code). Upon refusal, the registration is not stopped and is retried after 5 seconds.
−
* Registration is when Tmedia sends a SIP REGISTER to a Registrar, and gets a response which could be accepted (200 OK) or refused (anything else) that may require further action
+
−
* If Authentication is required, the Registrar returns a 401 Unauthorized response with a WWW-Authenticate header
+
−
* The WWW-Authenticate header contains nonce to encrypt user’s communications password, user then sends a second REGISTER containing an Authorization header with the user's encrypted password
+
 
* Even if there is no call on the system, Tmedia will send SIP REGISTER
 
* Even if there is no call on the system, Tmedia will send SIP REGISTER
−
* If it is not registered already, the Tmedia will send SIP REGISTER at 5 seconds interval, otherwise it is at the half of the minimum registration negotiated with the remote proxy (endpoint)
 
−
* The SIP REGISTER is "valid" for 3600 seconds
 
−
* Tmedia will send a new REGISTER (to refresh a registration) after half of the minimum registration negotiated, general use will be at 1800 seconds (3600/2)
 
 
* Sending SIP REGISTER will happen when the option [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] is selected for a specific SIP [[NAP]]
 
* Sending SIP REGISTER will happen when the option [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] is selected for a specific SIP [[NAP]]
 
* If you apply a new configuration and the option [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] is present it will start sending SIP REGISTER
 
* If you apply a new configuration and the option [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] is present it will start sending SIP REGISTER
  
−
===Register with negotiation (contact expire)===
 
−
 
−
[[Image:SIP_Register_negotiated_expire_time_example_1.png|600px]]
 
−
 
−
===Register with negotiation (contact expire not provided, default Expires header)===
 
−
 
−
[[Image:SIP Register negotiated expire time example 2.png|600px]]
 
−
 
−
===Register Authentication===
 
−
 
−
[[Image:SIP_Register_401_authentication_example.png|600px]]
 
−
 
−
===Register with no answer from registrar===
 
  
 +
===Register with no answer from registrar ===
 +
If it is not registered already, the Tmedia will send a new SIP REGISTER every 32 + 5 seconds interval until it receive a response from the Registrar
 +
*Over UDP (shown it the message flow bellow), the REGISTER request is retransmitted for 32 seconds before the request transaction timeout, then a new SIP REGISTER is sent after 5 seconds.
 +
*Over TCP, if the SIP registrar does not listen on the TCP port, a new TCP connection is retried every 5 seconds. If the TCP connection is established but no SIP responses returned by the Registrar, the transaction timeout after 32s and then a new SIP REGISTER is sent after 5 seconds.
 
[[Image:SIP_Register_no_answers.png|500px]]
 
[[Image:SIP_Register_no_answers.png|500px]]
  
 +
===Register expire negotiation ===
 +
The REGISTER request negotiate the contact binding expiration by adding "expires=3600" parameter to the contact header. The value is hardcoded to 3600 seconds.
 +
If the REGISTER response from the Registrar does not change the "expires" parameter:
 +
* The SIP REGISTER will be "valid" for 3600 seconds
 +
* Tmedia will send a new REGISTER (to refresh the registration) after half of the minimum registration negotiated, general use will be at 1800 seconds (3600/2)
  
−
[[Image:Tmedia SIP Registration Process with Expires.jpg|600px]]
+
The Registrar can change the "expires" contact parameter or the Expires header as shown in the two example below to negotiate a value different from 3600 seconds.
 +
==== Negotiation uses case 1: contact expires header ====
 +
In the example below, the Registrar changes the "expires" contact parameter.
  
−
[[Image:Tmedia SIP Registration Process with Authorization.jpg|550px]]
+
[[Image:SIP_Register_negotiated_expire_time_example_1.png|700px]]
  
 +
==== Negotiation uses case 2: no contact expires parameter; Expires header  ====
 +
In the example below, the Registrar removes the "expires" contact parameter and set the Expires header.
  
 +
[[Image:SIP Register negotiated expire time example 2.png|650px]]
  
−
 
+
===Register Authentication===
−
 
+
* If Authentication is required, the Registrar returns a 401 Unauthorized response with a WWW-Authenticate header
−
 
+
* The WWW-Authenticate header contains nonce to encrypt user’s communications password, user then sends a second REGISTER containing an Authorization header with the user's encrypted password
−
== Polling ==
+
[[Image:SIP_Register_401_authentication_example.png|1100px]]
−
* In Tmedia, option [[Parameter:_Poll_Remote_Proxy|"Poll Remote Proxy?"]] is enabled by default
+
−
* Tmedia SIP polling is using SIP OPTIONS method to "poke" a SIP [[NAP|Network Access Point (NAP)]] to see if it's alive or not, that is, [[NAP]] availability
+
−
* Upon a response from the SIP [[NAP]], Tmedia will determine whether to mark the [[NAP]] as up
+
−
* If the option [[Parameter:_Map_any_Response_to_Available_Status|"Map any response to available status"]] is unchecked, only a 200 OK to a SIP OPTIONS will bring the [[NAP]] up
+
−
* The first time a SIP [[NAP]] is added in configuration and configuration activated, Tmedia polls at 5 seconds, after that and general use is polling at 60 seconds
+
−
 
+
−
 
+
−
== [[NAP|Network Access Point (NAP)]] Availability ==
+
−
If [[Parameter:_Poll_Remote_Proxy|"Poll Remote Proxy?"]] and [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] are both checked, only the SIP OPTIONS answers will affect the [[NAP]] availability.
+
−
 
+
−
 
+
  
 
== Configuration ==
 
== Configuration ==
  
 +
*[[Toolpack:Allocating a SIP Network Access Point (NAP) F|Allocating a SIP NAP Configuration v3.0]]
 +
*[[Toolpack:Allocating a SIP Network Access Point (NAP) E|Allocating a SIP NAP Configuration v2.10]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) D|Allocating a SIP NAP Configuration v2.9]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) D|Allocating a SIP NAP Configuration v2.9]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) C|Allocating a SIP NAP Configuration v2.8]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) C|Allocating a SIP NAP Configuration v2.8]]
 +
<div class="mw-collapsible mw-collapsed" data-collapsetext="other versions" data-expandtext="Click here for other versions" style="width: 400px;">
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) B|Allocating a SIP NAP Configuration v2.7]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) B|Allocating a SIP NAP Configuration v2.7]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) B|Allocating a SIP NAP Configuration v2.6]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) B|Allocating a SIP NAP Configuration v2.6]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) A|Allocating a SIP NAP Configuration v2.5]]
 
*[[Toolpack:Allocating a SIP Network Access Point (NAP) A|Allocating a SIP NAP Configuration v2.5]]
 +
</div>
 +
*[[Configuring SIP Registration to SIP Proxy|Configuring SIP Registration to SIP Proxy]]
  
 
== References ==
 
== References ==

Latest revision as of 05:48, 21 November 2019


Contents

SIP Registrar

A SIP registrar’s role is to accept REGISTER requests with an Address Of Record (URI) and write the associated contact bindings to a location service. The location service is a logical entity and is simply a database that contains a list of AOR to contact address bindings. Very often a registrar functions as a location service. It is also very common for a registrar/location service to be co-located with the proxy server for the same domain. The example below shows a typical registration transaction.

SIP Registration Process.jpg

Tmedia supports two modes for SIP Registration:

Registration per SIP NAP

The Tmedia supports to register a SIP NAP to a SIP proxy. Registration, can be used, for example, to authenticate the Tmedia Gateway IP address to a SIP provider proxy or SBC and allow the SIP traffic from the Tmedia to that SIP provider.

  • Registration is when Tmedia sends a SIP REGISTER to a Registrar, and gets a response which could be accepted (200 OK) or refused (4xx reason code). Upon refusal, the registration is not stopped and is retried after 5 seconds.
  • Even if there is no call on the system, Tmedia will send SIP REGISTER
  • Sending SIP REGISTER will happen when the option "Register to Proxy?" is selected for a specific SIP NAP
  • If you apply a new configuration and the option "Register to Proxy?" is present it will start sending SIP REGISTER


Register with no answer from registrar

If it is not registered already, the Tmedia will send a new SIP REGISTER every 32 + 5 seconds interval until it receive a response from the Registrar

  • Over UDP (shown it the message flow bellow), the REGISTER request is retransmitted for 32 seconds before the request transaction timeout, then a new SIP REGISTER is sent after 5 seconds.
  • Over TCP, if the SIP registrar does not listen on the TCP port, a new TCP connection is retried every 5 seconds. If the TCP connection is established but no SIP responses returned by the Registrar, the transaction timeout after 32s and then a new SIP REGISTER is sent after 5 seconds.

SIP Register no answers.png

Register expire negotiation

The REGISTER request negotiate the contact binding expiration by adding "expires=3600" parameter to the contact header. The value is hardcoded to 3600 seconds. If the REGISTER response from the Registrar does not change the "expires" parameter:

  • The SIP REGISTER will be "valid" for 3600 seconds
  • Tmedia will send a new REGISTER (to refresh the registration) after half of the minimum registration negotiated, general use will be at 1800 seconds (3600/2)

The Registrar can change the "expires" contact parameter or the Expires header as shown in the two example below to negotiate a value different from 3600 seconds.

Negotiation uses case 1: contact expires header

In the example below, the Registrar changes the "expires" contact parameter.

SIP Register negotiated expire time example 1.png

Negotiation uses case 2: no contact expires parameter; Expires header

In the example below, the Registrar removes the "expires" contact parameter and set the Expires header.

SIP Register negotiated expire time example 2.png

Register Authentication

  • If Authentication is required, the Registrar returns a 401 Unauthorized response with a WWW-Authenticate header
  • The WWW-Authenticate header contains nonce to encrypt user’s communications password, user then sends a second REGISTER containing an Authorization header with the user's encrypted password

SIP Register 401 authentication example.png

Configuration

References

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