Registration
From Snom User Wiki
Date: Sept-10-2004 Author:Christian Stredicke
Contents |
Abstract
This document describes the registration behaviour of the snom user agents. For the snom phone, the information provided here applies to versions 3.50 and higher.
Starting Registration
The registration starts when the name, the account, the registrar, the password or the Q-value of a line changes. 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.
Next Registration
When the UA received a 2xx response 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.
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.
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 RFC3261 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.
