Panoramisk

Annonce

On peut être passionné par la téléphonie et prendre soin de soi : "Faites du sport, faites du vélo" est la devise du site d'e-commerce lancé par l'un des auteurs de Panoramisk : bikeo. Si vous faites du vélo, que ce soit en ville, sur la route ou sur les chemins plus accidentés, n'hésitez pas à aller faire un petit tour sur www.bikeo.fr pour vos prochains achats verts.
En plus leur plate-forme de téléphonie utilise Asterisk, comme quoi on peut la convergence est une réalité.

Client registration using SIP: REGISTER

Registering a client in the SIP model is not mandatory, a session can be initiated with a peer without requiring a lookup in the SIP directory. But why is this method so important and how does it work? This article explains what is a registration in the SIP world and how it works with Asterisk.

Introduction

SIP is a protocol dedicated to multimedia session establishment and management between peers. In this respect, SIP is considered as a peer-to-peer protocol. Today, we are mainly using SIP in the voice world in order to establish phone calls, but a lot of applications are supported by SIP on top of a session.
In order to be able to establish a session (in our case a phone call), one peer needs to know how and where to reach the other peer. This function is provided by the proxy which is able to lookup the destination address and establish the relationship between both peers. The lookup is performed within a kind of directory and maintained by either static routing (call routing in this case) or dynamic registration of clients.

The SIP proxy server is looking in the directory for IP Information related to the session’s destination. We are talking about User Agent (UA) for the database key and IP information related are address, protocol (TCP or UDP) and port number. Each UA is hosted on an IP machine (ie an IP phone) and uses UDP (or TCP) ports in order to communicate. The default SIP port number is 5060 but it is not mandatory to use this one. When a proxy server is asked to put in relation two members of a session, it should find IP information related to each UA.

This is the main role of the registrar to collect IP information from the UA and feed the directory in order for other SIP components (ie proxy) to be able to manipulate sessions.

Since initial IP information are only known by the client (UA), we require a specific communication between the UA and the registrar in order to inform this one. This specific exchange is performed at the UA start-up and on a regular basis in order for the registrar to clean the directory from old (and thus invalid) records. By default the exchange is done every hour, but this period can be adjusted.

The registration phase between each UA and the registrar server is using a SIP specific method called REGISTER.

Parameters

First, each UA willing to establish a session should know how to reach the other UA. Generally a SIP component is used for this purpose: the proxy. The proxy information should be available in the UA configuration. This is either done statically with a configuration in the UA maintained through the web interface, a file or through automatic provisioning if supported by the UA application. It could also be possible to use specific records available in a DNS service, for more information on this topic, please have a look to “SIP registry and DNS SRV”.

How does it work

Here below is a registration exchange trace between an IP phone (at 192.168.16.181) and an Asterisk server (acting as a registrar, at 192.168.16.40). The network trace has been collected with Wireshark and exported as text:

Session Initiation Protocol
    Request-Line: REGISTER sip:192.168.16.40 SIP/2.0
        Method: REGISTER
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 192.168.16.181:32262;branch=z9hG4bK-d87543-624dc77d9c1b9618-1--d87543-;rport
        Max-Forwards: 70
        Contact: <sip:11@192.168.16.181:32262;rinstance=9dd2c78e6ac0a5a5>
        To: "soft 2"<sip:11@192.168.16.40>
        From: "soft 2"<sip:11@192.168.16.40>;tag=394aa21c
        Call-ID: YjYzYTAyNzM0NGVkYmEzZWMyMzJmNzMzNDZjMzIyMjg.
        CSeq: 1 REGISTER
        Expires: 3600
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
        User-Agent: X-Lite release 1011s stamp 41150
        Content-Length: 0

Main information we could see in this exchange are:

the SIP method: REGISTER
information regarding the UA, these are in the Contact field: URI 11@192.168.16.181:32262 in which we found the identifier (phone number in this case, 11), the IP address (192.168.16.181) and port number on which the UA is listening for SIP messages (32262). You can see here the SIP port is not the standard one (5060), but since it is not mandatory to use the standard one we have to put it in the URI.

The answer from the registrar should be 200 OK in order for the UA to be known in the directory. Here is the answer frame from our Asterisk server:

Session Initiation Protocol
    Status-Line: SIP/2.0 200 OK
        Status-Code: 200
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 192.168.16.181:32262;branch=z9hG4bK-d87543-624dc77d9c1b9618-1--d87543-;received=192.168.16.181;rport=32262
        From: "soft 2"<sip:11@192.168.16.40>;tag=394aa21c
        To: "soft 2"<sip:11@192.168.16.40>;tag=as22b3d595
        Call-ID: YjYzYTAyNzM0NGVkYmEzZWMyMzJmNzMzNDZjMzIyMjg.
        CSeq: 1 REGISTER
        User-Agent: Asterisk PBX
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
        Supported: replaces
        Expires: 3600
        Contact: <sip:11@192.168.16.181:32262;rinstance=9dd2c78e6ac0a5a5>;expires=3600
        Date: Sun, 07 Oct 2007 13:00:11 GMT
        Content-Length: 0

In the answer we can find:

message type: OK
same contact content as in the register message
same Call-Id field which identifies the exchange, since this one can use UDP as the transport medium.

Validation

Once the registration is performed, the registrar should be able to restitute information contained in the directory. Each SIP PBX should therefor have a command or a way to gather which SIP UA are registered and the IP information related. With Asterisk, the sip show peers command on the CLI is able to list all configured peers and there respective status:

asterisk41*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status
11/11                      192.168.16.181   D          32262    OK (3 ms)

On this output we can see the UA identifier (11), the IP address and the port number. Asterisk is not providing information about the protocol used to talk to the client since supporting only UDP for now¹. The last information is the status and the monitoring delay between the Asterisk server and the UA, see also “Network transit and peer qualification”.

Troubleshooting

In the case one UA is not able to get registered, it could be useful to see the cause and if registration messages are well exchanged. In the Asterisk world, most of the time, the UA should be listed in the sip.conf configuration file before a registration message could be received. If your configuration is good, but the UA is still not in the directory, you can use the debug mode in the sip part. It is also possible to use a network analyzer if you have access to the network layer.

Here below is a debug trace taken on the Asterisk CLI with an UA trying to register:

asterisk41*CLI> sip set debug ip 192.168.16.181
<--- SIP read from 192.168.16.181:38192 --->
REGISTER sip:192.168.16.40 SIP/2.0
Via: SIP/2.0/UDP 192.168.16.181:38192;branch=z9hG4bK-d87543-2365443e5f277647-1–d87543-;rport
Max-Forwards: 70
Contact: <sip:not_good@192.168.16.181:38192;rinstance=b4480613d7542907>
To: “soft 2″<sip:not_good@192.168.16.40>
From: “soft 2″<sip:not_good@192.168.16.40>;tag=e474c93c
Call-ID: OTkwODU3ZjUwNjAyYmU4ZTk2OWM2MTdmYjE3ZTk3MGU.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite release 1011s stamp 41150
Content-Length: 0

<— Transmitting (NAT) to 192.168.16.181:38192 —>
SIP/2.0 404 Not found
Via: SIP/2.0/UDP 192.168.16.181:38192;branch=z9hG4bK-d87543-2365443e5f277647-1–d87543-;received=192.168.16.181;rport=38192
From: “soft 2″<sip:not_good@192.168.16.40>;tag=e474c93c
To: “soft 2″<sip:not_good@192.168.16.40>;tag=as4f1da0ea
Call-ID: OTkwODU3ZjUwNjAyYmU4ZTk2OWM2MTdmYjE3ZTk3MGU.
CSeq: 1 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 0

Asterisk is receiving a REGISTER message but the proposed contact (not_good) is not specified in the sip.conf, therefor Asterisk answers back with a 404 not found message².

Conclusion

The SIP REGISTER method is used to register mobile clients (UA) in the internal routing directory. The stored informations allow resolution of IP information versus UA identifier. This registration method is mainly used when clients are using temporary IP addresses, like in a DHCP domain. Mainly IP phone are using the registration, but also any IPBX when talking to an IP centrex. The IP telcos are using the registration in order not to maintain voice routing tables and not managing IP addresses of their customers who can use any kind of Internet provider.

Registration is useless whenever the other peer is well known with regards to IP informations, in that case we are talking about call routing and tables are static. This is mainly used for PBX trunk interconnections, gateways and SBC³.

Asterisk is implementing the SIP registrar server feature and clients can registered themselves to Asterisk in order to be reachable. But Asterisk can also register itself to another registrar, in that case it is acting as an standard UA. The sip.conf configuration file is the place where can be configured both aspects: each client in a dedicated section and each registration using the register => syntax.

SIP devices should support both UDP and TCP, but… [↩]
you can see here that the return code is similar to the HTTP page not found code web servers are returning when a browser tries to access an unknown page [↩]
Session Border Controller [↩]