SIP Registration

From TBwiki
(Difference between revisions)
Jump to: navigation, search
(→Configuration)
 
(48 intermediate revisions by 4 users not shown)
Line 1: Line 1:
  
−
= 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.
 
  
−
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.
+
== SIP Registrar ==
 +
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.
  
 +
[[Image:SIP Registration Process.jpg|400px]]
  
−
== Enbloc Signaling ==
+
Tmedia supports two modes for SIP Registration:
−
The enbloc signaling method transmits the number as a complete entity in a single message. When using enbloc signaling, the complete number is sent in the IAM to set up a call. This is much more efficient than overlap signaling, which uses multiple messages to transport the number. Enbloc signaling is better suited for use where fixed-length dialing plans are used, such as in North America. The right diagram illustrates the use of enbloc signaling.
+
* 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 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 [[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
  
−
== Overlap Signaling ==
 
−
Overlap signaling sends portions of the number in separate messages as digits are collected from the originator. Using overlap signaling, call setup can begin before all the digits have been collected. When using the overlap method, the IAM contains the first set of digits. The Subsequent Address Message (SAM) is used to transport the remaining digits. The bottom right diagram illustrates the use of overlap signaling. Local exchange A collects digits from the user as they are dialed. When enough digits have been collected to identify the next exchange, an IAM is sent to exchange B. When tandem exchange B has collected enough digits to identify the next exchange, it sends an IAM to exchange C; exchange C repeats this process. After the IAM is sent from exchange C to exchange D, the destination exchange is fully resolved. Exchange D receives SAMs containing the remaining digits needed to identify the individual subscriber line.
 
  
−
When using dialing plans that have variable length numbers, overlap signaling is preferable because it decreases post-dial delay. As shown in the preceding example, each succeeding call leg is set up as soon as enough digits have been collected to identify the next exchange.
+
===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]]
  
−
Interdigit timing is performed as digits are collected from a subscriber line. When an exchange uses variable length dial plans with enbloc signaling, it must allow interdigit timing to expire before attempting to set up the call. The exchange cannot start routing after a specific number of digits have been collected because that number is variable. By using overlap signaling, the call is set up as far as possible, waiting only for the final digits the subscriber dials. Although overlap signaling is less efficient in terms of signaling bandwidth, in this situation it is more efficient in terms of call set-up time.
+
===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.
  
−
== TelcoBridges and Overlap Signaling ==
+
[[Image:SIP_Register_negotiated_expire_time_example_1.png|700px]]
−
Enbloc Signaling is the default mode of operation on the Tmedia units. TelcoBridges supports Overlap Signaling as part of its SS7 and ISDN signaling stack implementation. It also supports both Overlap sending and receiving in ISDN and SS7.
+
  
 +
==== 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.
  
−
== Overlap Sending ==
+
[[Image:SIP Register negotiated expire time example 2.png|650px]]
−
When enabling the Overlap Sending in NAP Overlap Parameters
+
−
* TMedia will send maximum of up to 30 digits, when the Extra called number bytes in ISUP stack is selected (by default)
+
−
* Extra called number bytes is an option located in ISUP stack configuration below
+
−
 
+
−
 
+
−
[[Image:Extra called number bytes.jpg]]
+
−
 
+
−
 
+
−
* The sent digits are distributed over IAM (up to 16 digits) and SAM (for remaining digits)
+
−
 
+
−
[[Image:Overlap Sending.jpg|400px]]
+
−
 
+
−
* If Extra called number bytes is deselected, only up to 16 digits can be sent in IAM only
+
−
 
+
−
 
+
−
== Overlap Receiving ==
+
−
When enabling the Overlap Receiving
+
−
* TMedia will receive maximum of up to 30 digits, when the Extra called number bytes in ISUP stack is selected (by default)
+
−
* If Extra called number bytes is deselected, only maximum of 16 digits can be received in IAM
+
−
* When Overlap Receiving Timeout is set to 0, it will wait forever to receive total number of CdPN
+
−
* For Overlap Receiving Inter Digit Timeout, a 20 seconds value is an ok value
+
−
* Overlap Receiving Expected Digits value must be 0 or a specific number of digits, for a 0 value this implies it will expect up to 30 digits to be received
+
−
* In most cases, it is difficult to set a specific Overlap Receiving Expected Digits value since calls can come with more or less digits
+
−
* Below illustrates when Overlap Receibing Expected Digits value is 0, and TMG is expecting SAM and waiting for Inter Digit to timeout without knowing the number of total digits to expect
+
−
 
+
−
 
+
−
[[Image:Overlap Receiving Inter_Digit Timeout.jpg|400px]]
+
−
 
+
−
 
+
−
* An other than 0 value for Overlap Receiving Expected Digits is used to speed up PDD (post-dial delay), instead of waiting for the 20 seconds total timeout
+
  
 +
===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:Configuring Overlap C|ISDN/NFAS configuration v2.9]]
+
*[[Toolpack:Allocating a SIP Network Access Point (NAP) F|Allocating a SIP NAP Configuration v3.0]]
−
*[[Toolpack:Configuring Overlap B|ISDN/NFAS configuration v2.8]]
+
*[[Toolpack:Allocating a SIP Network Access Point (NAP) E|Allocating a SIP NAP Configuration v2.10]]
−
*[[Toolpack:Configuring Overlap A|ISDN/NFAS configuration v2.7 and v2.6]]
+
*[[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]]
 +
<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.6]]
 +
*[[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]
 +
*[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

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