SIP Registration Process


The registration is a way to know the location (FQDN/IP address) of the SIP user-agent. The user-agent exchanges a set of SIP messages with the registrar/Proxy server to register its location in the server’s database. In addition to the user-agent location the registrar/proxy server can receive CPL (Call Processing Language) script.

RFC 3665 shows different registration scenarios: successful new registration, update of current registration, request for current contact list, cancellation of the registration, and unsuccessful registration. In this article i will explain only the first scenario (Successful New Registration).

Investigation of a Successful New Registration



Message F1 is explained in the figure below.

Register 1VIA header field defines 3 important informations: Transport, Last SIP Hop , and the Transaction-ID. In the previous figure we can see the transport as SIP/2.0/TLS. This means SIP messages will be secured carried by TLS transport. The last hop here is the The branch parameter in the VIA header field which is marked by star (*) in the figure, represents the identification of the current transaction. To be able to identify the transaction it must be unique across space and time for all requests sent by the user-agent except CANCEL and ACK for non-2xx responses. CANCEL has the same branch parameter as the request it cancels. An ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. This is part of RFC 3261. Making the Branch parameter begins by the string z9hG4bK” means it is compatible with RFC 3261 regarding uniqueness property.

Each proxy adds its own VIA. The VIA header field is used for routing replies backward without DNS lookup.

Max-Fowards header field defines the maximum number of hops the SIP request can do.

From/To header field: From header field defines the user who initiates the request The ”display-name” is optional and it is used for rendering purposes on the human user-interface (GUI) of the user-agent. For example ”A is calling you” text appears on the screen of the calle.

To header header field represents the calle (user who receives the call). For example ”You are calling B” text appears on the screen of the caller. The From and To header fields are logical identities (AORs and optional display-names). NO IP addresses or FQDNs are allowed here since these are not logical. From and To header fields are not used in routing of the SIP messages.

The AOR (Address Of Record) in both From and To header fields is the same in the registration because registration is not a call.

The From-tag (the tag parameter in the From header field) with To-tag and Call-ID identify the dialog (peer-to-peer relationship between caller and calle).

Call-ID header filed identify the group of SIP messages (requests and responses) in the dialog. All must have the same Call-ID. Call-ID is calculated from random string and the phone’s hostname or IP address. This can not fully identify the dialog (the relationship between the caller and the calle) so we need “From-tag” and “To-tag”.

The generation of Call-ID is critical. The question is “When Call-ID must be globally unique ?”

The Call-ID must be selected by the UAC as globally unique over time and space if the new request is created outside any dialog.

CSeq header field used to order transactions within a dialog. Two CSeq header fields are considered equal if the sequence number and the request method are identical.

Contact header field contains SIP or SIPS URI that represents direct route to contact user-agent A. Usually it looks like: username@FQDN (Preferred) or username@IP-Address . For example: as shown in the figure but it can be also A@

You might have several SIP devices all registered under the same address of record (

Now we have finished the first message in the registration process (REGISTER F1).

F2: 401 Unauthorized

This response is shown in the figure below.

401unauthorized1WWW-Authenticate header field contains the authentication challenge sent by the server. It contains the information the user-agent needs to generate the checksum. The word “Digest” indicates the authentication scheme. The parameters are:

realm which is the associated protection domain,

qop (Quality of Protection) is optional. It can be either “auth” for authentication and “auth-int” for authentication and integrity.

nounce: unique string generated by the server.

opaque: optional, generated by the server to be returned in the subsequent requests.

stale: is flag and it is optional. It indicates if the nounce value in the previous request is stale.

algorithm:the algorithm used for checksum. It is optional and the default is MD5.


The user-agent generates what is called Authorization header and resend the original registration request (REGISTER F1) with the Authorization header field in it. The figure below shows REGISTER F3.

register-2Authorization header field involves mainly the response parameter which is the calculated checksum. The Cseq is 2 now since the request is considered new.

F4: 200 OK

If the authentication is success the server send 200 OK.

200ok1This way is the same way used in HTTP to authenticate the user. It is called WWW-authentication. There is another type of authentication used in SIP called Proxy-Authentication. Here the client receives 407 authentication challenge instead of 401.

Now other scenarios of the registration explained in the RFC 3665 will be easy to understand. Also other SIP Processes.

More Information


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s