SIP Registration

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(Configuration)
 
(32 intermediate revisions by 4 users not shown)
Line 2: Line 2:
  
 
== SIP Registrar ==
 
== SIP Registrar ==
A registrar is a SIP endpoint that accepts REGISTER requests and places the information it receives in those requests into a location service for the domain it handles. The location service links one or more IP addresses to the SIP URI of the registering agent. The URI uses the sip: scheme, although other protocol schemes are possible, such as tel:. More than one user agent can register at the same URI, with the result that all registered user agents receive the calls to the URI.
+
A SIP [https://en.wikipedia.org/wiki/Session_Initiation_Protocol#Registrar 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 registrars are logical elements, and are commonly co-located with SIP proxies. But it is also possible and often good for network scalability to place this location service with a redirect server.
+
  
 
[[Image:SIP Registration Process.jpg|400px]]
 
[[Image:SIP Registration Process.jpg|400px]]
  
Tmedia does not support a registrar, so for example, a SIP phone client cannot register to a Tmedia. If clients send SIP requests and responses directly to the other clients in point-to-point mode and not through a proxy, REGISTER is not required. In this case, clients are required to know the IP addresses 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]]
== Polling ==
+
** [[Toolpack:Creating_a_SIP_Domain_SBC_A|Configuration of Tmedia's registration forwarding]]
* In Tmedia, option "Poll Remote Proxy?" is enabled by default
+
* The Tmedia registers itself to the SIP Proxy (per SIP NAP, as explained below in current page)
* Tmedia SIP polling is using SIP OPTIONS method to "poke" a SIP 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
+
* This is true, only if the option "Map any response to available status" is checked (by default), otherwise, only a 200 OK to a SIP OPTIONS will bring the NAP up
+
* With "Map any response to available status" checked, 200-600 answer response can return from OPTIONS request, with these response the NAP is considered up
+
* The first time a SIP NAP is added in configuration and configuration activated, Tmedia polls at 5s, after that and general use is polling at 60s
+
 
+
  
== Registration ==
+
== Registration per SIP NAP ==
* Registration is when Tmedia sending SIP REGISTER to Registrar, and getting answer response which could be accepted (200 OK) or refused (anything else) that may require further action
+
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
 
* 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 5s interval, otherwise it is at the half of the minimum registration negotiated with the remote proxy(endpoint)
+
* Sending SIP REGISTER will happen when the option [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] is selected for a specific SIP [[NAP]]
* The SIP REGISTER is "valid" for 3600s
+
* If you apply a new configuration and the option [[Parameter:_Register_to_Proxy|"Register to Proxy?"]] is present it will start sending SIP REGISTER
  
[[Image:SIP Registration Process with Expires.jpg|400px]]
 
  
 +
===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]]
  
* There is no way to extend SIP registration, so Tmedia has to send a new REGISTER (to refresh a registration) after half of the minimum registration negotiated, general use will be at 1800s (3600/2)
+
===Register expire negotiation ===
* Sending SIP REGISTER will happen when the option "Register to Proxy?" is selected for a specific SIP NAP
+
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 you apply a new configuration and the option "Register to Proxy?" is present it will start sending SIP REGISTER
+
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.
  
== Nap Availability ==
+
[[Image:SIP_Register_negotiated_expire_time_example_1.png|700px]]
If "Polling Remote Proxy?" and "Register to Proxy?" are both checked, only the SIP OPTIONS answers will affect the NAP availability.
+
  
 +
==== 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
 +
[[Image:SIP_Register_401_authentication_example.png|1100px]]
  
 
== 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) 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 ==
*[http://en.wikipedia.org/wiki/Session_Initiation_Protocol Wikipedia article]
+
*[http://en.wikipedia.org/wiki/Session_Initiation_Protocol#Registrar Wikipedia registrar article]
 
*[https://andrewjprokop.wordpress.com/2014/05/29/understanding-sip-registration/ Understanding SIP Registration]
 
*[https://andrewjprokop.wordpress.com/2014/05/29/understanding-sip-registration/ Understanding SIP Registration]
 +
*[http://toncar.cz/Tutorials/VoIP/VoIP_Protocols_SIP_Call_Flow.html VoIP Protocols:SIP Call Flow - Toncar.cz]
  
  
 
[[category:Glossary]]
 
[[category:Glossary]]
 
[[Category:Revise on Major]]
 
[[Category:Revise on Major]]

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

Personal tools