Category:HowTo:SIP

From Snom User Wiki

Jump to: navigation, search
  • Date: Sept-10-2004, Author:Christian Stredicke
  • Last Change: Jan-22-2009, Edited:Alexander Feldt

Contents

Abstract

This document describes the registration behavior of the snom user agents. For the snom phone, the information provided here applies to the following firmware versions:

Starting Registration

The registration starts when one of the following parameters of a line (SIP identity) change:

  1. account
  2. registrar
  3. password or
  4. Q-value

If there was another successful registration on the line, the old registration is deleted first.

The registration of all lines is started if the IP address changes. This includes the address of the UA itself and the external address, e.g. allocated by STUN or UPnP.

Registration w/o authentication

Sent to udp:pbx:5060 at 22/1/2009 15:31:48:066 (526 bytes):

REGISTER sip:pbx SIP/2.0
Via: SIP/2.0/UDP phoneIP:5060;branch=z9hG4bK-b12m9r9qvqh3;rport
From: "Ext 905" <sip:905@pbx>;tag=3xq79cc9he
To: "Ext 905" <sip:905@pbx>
Call-ID: 3c268399b04e-b2e3tpb6b9eb
CSeq: 12 REGISTER
Max-Forwards: 70
Contact: <sip:905@phoneIP:5060>;reg-id=1;q=1.0;+sip.instance="
 <urn:uuid:e960df68-8f5d-4fec-aab4-1678c7bd76a0>"
User-Agent: snom370/7.3.14
Supported: gruu
Allow-Events: dialog
X-Real-IP: phoneIP
Expires: 3600
Content-Length: 0

...

Received from udp:pbx:5060 at 22/1/2009 15:31:48:272 (524 bytes):

SIP/2.0 200 OK
Via: SIP/2.0/UDP phoneIP:5060;branch=z9hG4bK-b12m9r9qvqh3;received=phoneIP;rport=5060
From: "Ext 905" <sip:905@pbx>;tag=3xq79cc9he
To: "Ext 905" <sip:905@pbx>;tag=as3b3fb9e5
Call-ID: 3c268399b04e-b2e3tpb6b9eb
CSeq: 12 REGISTER
User-Agent: pbx name
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Expires: 3600
Contact: <sip:905@phoneIP:5060>;expires=3600
Date: Thu, 22 Jan 2009 14:31:49 GMT
Content-Length: 0

Registration with authentication

SIP Trace

Sent to udp:192.168.168.254:5060 at 22/7/2011 16:01:03:943 (811 bytes):

REGISTER sip:sip.training.com SIP/2.0
Via: SIP/2.0/UDP 192.168.168.16:3072;branch=z9hG4bK-135uwborv32i;rport
From: "Ext B" <sip:201@sip.training.com>;tag=q1uzrbrk3e
To: "Ext B" <sip:201@sip.training.com>
Call-ID: 3d7a263ccb09-48m3t75aprh3
CSeq: 1814 REGISTER
Max-Forwards: 70
Contact: <sip:201@192.168.168.16:3072;line=1by3v3rp>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:daf2480e-aac7-47c7-8ff0-c4960497e1a5>";audio;mobility="fixed";duplex="full";description="snom821";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom821/8.4.18
Allow-Events: dialog
X-Real-IP: 192.168.168.16
Supported: path, gruu
WWW-Contact: <http://192.168.168.16:80>
WWW-Contact: <https://192.168.168.16:443>
Expires: 3600
Content-Length: 0

Received from udp:192.168.168.254:5060 at 22/7/2011 16:01:03:992 (478 bytes):

SIP/2.0 401 Authentication Required
Via: SIP/2.0/UDP 192.168.168.16:3072;branch=z9hG4bK-135uwborv32i;rport=3072
From: "Ext B" <sip:201@sip.training.com>;tag=q1uzrbrk3e
To: "Ext B" <sip:201@sip.training.com>;tag=d4c56b4a46
Call-ID: 3d7a263ccb09-48m3t75aprh3
CSeq: 1814 REGISTER
User-Agent: snom-PBX/2011-4.2.0.3981
WWW-Authenticate: 
 Digest realm="sip.training.com",
 nonce="f6811eb6d6a55c96e7cd43481e9a2d92",
 domain="sip:sip.training.com",
 algorithm=MD5
Content-Length: 0

The "401 Unauthorized" request basically tells the SIP User Agent to authenticate the SIP account properly. This is done the following way:

  1. Use the Digest algorithm indicated in the WWW-Authenticate- Header, usually this is MD5
  2. Calculate the response using (this description
    1. string1 = MD5(username:name_of_realm:password) = user_hash Parameter, which can be provisioned onto snom IP phones
    2. string2 = MD5(REGISTER:uri) or (INVITE:uri) or (SUBSCRIBE:uri)
    3. response = MD5(string1:nonce:string2)
  3. Example: We use an online md5 generator
    1. string1 = MD5(201:sip.training.com:201) = cfa974fe3654f202575b07f30b791f31
    2. string2 = MD5(REGISTER:sip:sip.training.com) = 16ce7eedaf09fb923be258573e97d2b2
    3. response = MD5(cfa974fe3654f202575b07f30b791f31:f6811eb6d6a55c96e7cd43481e9a2d92:16ce7eedaf09fb923be258573e97d2b2) = ae788db72020233e3ed2a303f57ffac0
Sent to udp:192.168.168.254:5060 at 22/7/2011 16:01:04:000 (1000 bytes):

REGISTER sip:sip.training.com SIP/2.0
Via: SIP/2.0/UDP 192.168.168.16:3072;branch=z9hG4bK-krx2fj328iyk;rport
From: "Ext B" <sip:201@sip.training.com>;tag=q1uzrbrk3e
To: "Ext B" <sip:201@sip.training.com>
Call-ID: 3d7a263ccb09-48m3t75aprh3
CSeq: 1815 REGISTER
Max-Forwards: 70
Contact: 
 <sip:201@192.168.168.16:3072;line=1by3v3rp>;
 reg-id=1;
 q=1.0;
 +sip.instance="<urn:uuid:daf2480e-aac7-47c7-8ff0-c4960497e1a5>";
 audio;
 mobility="fixed";
 duplex="full";
 description="snom821";
 actor="principal";
 events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom821/8.4.18
Allow-Events: dialog
X-Real-IP: 192.168.168.16
Supported: path, gruu
WWW-Contact: <http://192.168.168.16:80>
WWW-Contact: <https://192.168.168.16:443>
Authorization: Digest
 username="201",
 realm="sip.training.com",
 nonce="f6811eb6d6a55c96e7cd43481e9a2d92",
 uri="sip:sip.training.com",
 response=" ae788db72020233e3ed2a303f57ffac0",
 algorithm=MD5
Expires: 3600
Content-Length: 0

Received from udp:192.168.168.254:5060 at 22/7/2011 16:01:04:019 (403 bytes):

SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.168.16:3072;branch=z9hG4bK-krx2fj328iyk;rport=3072
From: "Ext B" <sip:201@sip.training.com>;tag=q1uzrbrk3e
To: "Ext B" <sip:201@sip.training.com>;tag=d4c56b4a46
Call-ID: 3d7a263ccb09-48m3t75aprh3
CSeq: 1815 REGISTER
Contact: <sip:201@192.168.168.16:3072;line=1by3v3rp>;expires=362
Supported: path
Date: Fri, 22 Jul 2011 14:00:56 GMT
Content-Length: 0

Next Registration

When the UA received a 2xx response(Status-Code, here: SIP/2.0 200 OK) on REGISTER, it goes through the list of contacts and looks for the line parameter. If it was found, it gets the Expires header from that contact.

SIP Trace with Expire Header

Received from udp:pbx:5060 at 28/1/2009 15:04:20:832 (511 bytes):
SIP/2.0 200 OK
Via: SIP/2.0/UDP phoneIP:2048;branch=z9hG4bK-qvvcux6f9eof;received=phoneIP;rport=2048
From: <sip:505@pbx>;tag=ivpmlo86fa
To: <sip:505@pbx>;tag=as5cad4ef0
Call-ID: 3c26701c05ad-qo0zrjm07dye
CSeq: 100 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Expires: 60
Contact: <sip:505@phoneIP:2048;line=xzqai69d>;expires=60
Date: Wed, 28 Jan 2009 14:04:22 GMT
Content-Length: 0


If no expires was set or no match for the line parameter was found, it gets the expiry from the packet itself (“Expires” header). The UA supports expiry indications in seconds as well as the indication in absolute time. However, the absolute time obviously needs the proper initialization of the time (NTP). We recommend the usage of the number of seconds.

If the expires is less than 15 seconds, the UA assumes that there is a problem and changes the expiry time to 600 seconds. Expiry times are limited to 2000000 seconds (approx. 23 days).

It also searches a parameter called “display-expires” in the contact list. This parameter may include the number of seconds after which the UA should display that the expiration expires (see NR below).

For TCP and TLS connections, the phone will keep the connection open during the whole expiry time. The phone expects SIP traffic to go through this TCP/TLS connection. This is a little bit tricky, because the port number if not the TCP/TLS port where the phone accepts connections. If the server closes this TCP/TLS connection, it will be difficult to contact the phone via TCP/TLS (however, SIP server must not close the connection).

After a successful registration, the phone will reregister after half of the expired registration time. (see the SIP trace below)

Received from udp:pbx:5060 at 28/1/2009 15:04:20:832 (511 bytes):
SIP/2.0 200 OK
Via: SIP/2.0/UDP phoneIP:2048;branch=z9hG4bK-qvvcux6f9eof;received=phoneIP;rport=2048
From: <sip:505@pbx>;tag=ivpmlo86fa
To: <sip:505@pbx>;tag=as5cad4ef0
Call-ID: 3c26701c05ad-qo0zrjm07dye
CSeq: 100 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
 Expires: 60
Contact: <sip:505@phoneIP:2048;line=xzqai69d>;expires=60
Date: Wed, 28 Jan 2009 14:04:22 GMT
Content-Length: 0
Sent to udp:pbx:5060 at 28/1/2009 15:04:50:860 (691 bytes):
REGISTER sip:pbx SIP/2.0
Via: SIP/2.0/UDP phoneIP:2048;branch=z9hG4bK-yy43chsk4ifz;rport
From: <sip:505@pbx>;tag=3i5wp99xf5
To: <sip:505@pbx>
Call-ID: 3c26701c05ad-qo0zrjm07dye
CSeq: 101 REGISTER
Max-Forwards: 70
Contact: <sip:505@phoneIP:2048;line=xzqai69d>;flow-id=1;
 <urn:uuid:c877ca37-3cd5-4884-8e26-128c6a8b8da1>";audio;mobility="fixed";duplex="full";
 q=1.0;+sip.instance="description="snom360";actor="principal";events="dialog";
 methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
User-Agent: snom360/7.1.39
Supported: gruu
Allow-Events: dialog
X-Real-IP: phoneIP
Expires: 60
Content-Length: 0

GRUU Support

The phone supports GRUU (draft-ietf-sip-gruu-02.txt). The offering of this feature can be disabled from the web interface. However, GRUU is necessary for successful attended transfers (the other user agents do not have to support GRUU in this case; they only need to support RFC 3261 URI properly). Therefore, we strongly recommend keeping GRUU enabled.

When receiving a successful response, the phone looks for a gruu contact header. If the header is present, it will use the gruu contact in further non-REGISTER communication with other user agents.

Example: SIP Trace

NAT Refresh

The phone looks for a header called “P-NAT-Refresh”. If this header is set, it will send keep-alive packets to the registrar port. The interval in seconds is indicated in the header.

The purpose if this header is to make the UA refresh the NAT binding. This is better than refreshing from the outside, because some NAT boxes limit the number of refreshes that may come from the outside and the refreshing from the internal side is less sensitive to network congestion problems (if a packet gets lost the NAT might not be refreshed).

The refresh packets are UDP packets that contain four zero bytes.

Registration Redirection

snom UA currently do not support the redirection of REGISTER requests.

Registration Failure

When the registration fails, the snom UA differentiates two cases:

In the first case the user agent does not receive anything from the network or it receives a 408 code. Examples for this case include that the network is unreachable, the domain does not exist or the registrar is down. In these cases it is ok to try the registration again soon; therefore the phone waits sixty seconds and tries again.

In the second case the UA receives an error-code from the network other than 408. In these cases the phone tries again after the last expiry time which it received from the registrar (or the proposed registration time if it did not receive a successful response from the registrar so far). In any case, it will at least wait thirty seconds.

Displaying “NR”

The letters NR on the screen indicate the user that there is a problem with the registration.

NR is displayed after a successful registration expires.

Even if in the meantime other registration attempts fail because of transport problems, the phone does not display NR until the previous successful registration expires. This behaviour seems reasonable because the registrar will most likely keep the registration alive during this time.

If the re-registration fails because of other errors (for example account has been deleted/disabled or password has been changed), the phone will display the NR ten seconds after the response has been received. The little time should allow other actions (like automatic setup of passwords, loading of settings) to change the situation.

If an initial registration fails and there is no successful response within sixty seconds, the phone will also show NR on the display.

This category currently contains no pages or media.

Personal tools
Interoperability