SIP Method : REGISTER

Note : This examples is showing one of my log being interpreted according to the example from E-multimedia : http://www.siptutorial.net/SIP/request.html. For the part which is not described in this tutorial, I refered to RFC 3261.

Also refer to Registration with Authentication, Registration with IPSec for the full context in which these message are being used.

In this page, I would not talk anything about the overall registration procedure. I will just focus on the contents in the REGISTER message itself. Actually, REGISTER message is one of the most important message in IMS/SIP protocol and it contains a lot of important information in it. Unterstanding the meaning of each parameters in registration would help you greatly with various troubleshooting situation. Followings are some of the examples of REGISTER message you may see in the field. Keep reading this page as often as possible until you become very familiar with all the details of the contents.

Contents

Example 1 : Basic Form

This example shows a basic IMS SIP REGISTER and the core headers that appear even before looking at service capability or IPSec negotiation. Use this example to identify the registration target, UE contact, route to the proxy, registration lifetime, and basic Authorization fields.

[ Line 1 ] REGISTER sip:ims.sharetechnote.com SIP/2.0

[ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3933794001smg;transport=UDP

[ Line 3 ] Expires: 3600

[ Line 4 ] Route: <sip:192.168.1.2:5060;lr>

[ Line 5 ] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0000054200000000

This SIP message clip highlights the following parameters: Via, Route, Expires, P-Access-Network-Info. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

[ Line 6 ] User-Agent: SP VOIP IMS 2.0

[ Line 7 ] Privacy: none

[ Line 8 ] Contact: <sip:+11234567890@192.168.1.15:5060>

[ Line 9 ] Authorization: Digest

This SIP message clip highlights the following parameters: Contact, Authorization. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

username="001010123456789@ims.sharetechnote.com",

realm="ims.sharetechnote.com",

uri="sip:ims.sharetechnote.com",

nonce="",

response=""

[ Line 10 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=2504745718

[ Line 11 ] To: <sip:+11234567890@ims.sharetechnote.com>

[ Line 12 ] Call-ID: 500949143@192.168.1.15

[ Line 13 ] CSeq: 1 REGISTER

[ Line 14 ] Max-Forwards: 70

[ Line 15 ] Content-Length: 0

This REGISTER clip highlights Request-URI, Via, Expires, Route, P-Access-Network-Info, User-Agent, Privacy, Contact, Authorization, From, To, Call-ID, CSeq, Max-Forwards, and Content-Length. The most useful troubleshooting parameters are Request-URI and Route for routing, Contact for the UE binding, Expires for registration lifetime, and Authorization for the private identity and digest fields.

[ Line 1 ] The first line of the text-encoded message is called Request-Line. It identifies that the message is a request. It has format : Method SP Request-URI SP SIP-Version CRLF

Method : REGISTER

SP : Single Space

Request-URI : sip:ims.sharetechnote.com

SP : Single Space

SIP-Version : SIP/2.0

Note : The most important part in this line is Request-URI. UE specifies the domain name of the IMS Server (P-CSCF) in this field. UE get the domain name mostly from USIM/ISIM or depending on UE implementation, it may get it from UE's internal setting.

[ Line 2 ] Via:

This SIP message clip highlights the following parameters: Via. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This represents the local address of the first node (192.168.1.15:5060 in this case which is same as the caller) where it is expecting the responses to come

[ Line 3 ] Expires :

This SIP message clip highlights the following parameters: Expires. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

The Expires header field gives the relative time after which the message (or content) expires. The unit is sec. (See "20.19 Expires" of RFC 3261). In case of this example, it means "REGISTER" would expire in 3600 seconds. It means if UE does not renew the registration, the registration status will be cancelled.

[ Line 4 ] Route:

This SIP message clip highlights the following parameters: Route. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This field is used to force routing for a request through the listed set of proxies. This means that the 'REGISTER' message should go through the proxy 192.168.1.2:5060. (See "20.34 Route" of RFC 3261)

[ Line 8 ] Contact:

This SIP message clip highlights the following parameters: Contact. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This carries a SIP or SIPS URI that is a direct route to the originator. It contains a username and a fully qualified domain name(FQDN). It may also have an IP address.

Via field is used to send the response to the request. Contact field is used to send future requests. That is why the 200 OK response from the recipient goes to the caller through proxies. But when the recipient generates after the 200 OK, it goes directly to the originator bypassing the proxies

[ Line 9 ] Authorization:

This SIP message clip highlights the following parameters: Authorization. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

The Authorization header field contains authentication credentials of a UA. (Refer to "22.2 User-to-User Authentication" of RFC 3261). This part will be described in detail in the example : Authentication Information

[ Line 10 ] From:

This SIP message clip highlights the following parameters: From. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This carries a display name and a SIP or SIPS URI "11234567890@ims.sharetechnote.com". It also contains a tag which is a pseudo-random sequence inserted by the SIP application. It works as an identifier of the caller in the dialog. In most case, the URI came from IMPU field in USIM/ISIM (also refer to User Identification), but sometimes (especially in development phase) it may come from UE's internal configuration. Most of IMS Server is using IMPU as one key in user data base, so if the IMPU is not stored in server data base. You may not get any response or Not Found error from the server.

[ Line 12 ] Call-ID:

This SIP message clip highlights the following parameters: Call-ID. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

It is a globally unique identifier of the call generated as the combination of a pseudo-random string and the softphone's IP address.The Call-ID is unique for a call. A call may contain several dialogs. Each dialog is uniquely identified by a combination of From, To and Call-ID.

[ Line 13 ] CSeq:

This SIP message clip highlights the following parameters: CSeq. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This shows an integer and a method name. When a transaction starts, the first message is given a random CSeq. After that it is incremented by one with each new message. It is used to detect non-delivery of a message or out-of-order delivery of messages

[Line 14 ] Max-Forwards :

This SIP message clip highlights the following parameters: Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This is used to limit the number of hops that this request may take before reaching the callee It is decreased by one at each hop. It is necessary to prevent the request from traveling forever in case it is trapped in a loop.

Example 2 : UE Capability - IMS over SMS

This example focuses on how IMS service capability is advertised inside the Contact header. In this case, the key difference is the SMS over IP feature tag, which tells the network that the UE supports IMS messaging service behavior in addition to ordinary registration.

Most of the contents are the same as Example 1. One thing I want you to pay attention is [Line 8]. It has some parameters starting with '+', this is a kind of UE capability information.

[ Line 1 ] REGISTER sip:test.3gpp.com SIP/2.0

[ Line 2 ] From: <sip:+11234567890@test.3gpp.com>;tag=3671736275

[ Line 3 ] To: <sip:+11234567890@test.3gpp.com>

[ Line 4 ] CSeq: 450510774 REGISTER

[ Line 5 ] Call-ID: 3671736255_186872264@2001:0:0:1::3

[ Line 6 ] Via: SIP/2.0/UDP [2001:0:0:1::3]:5060;branch=z9hG4bK74372383

[ Line 7 ] Max-Forwards: 70

[ Line 8 ] Contact: <sip:+11234567890@[2001:0:0:1::3]:5060>;

This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

reg-id=1;

+g.3gpp.csi.smsip;

+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

[ Line 9 ] Route: <sip:[2001:0:0:1::2]:5060;lr>

[ Line 10] P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010100010000000

[ Line 11] Content-Length: 0

[ Line 12] Authorization: Digest

This SIP message clip highlights the following parameters: Route, Authorization, P-Access-Network-Info, Content-Length. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

[ Line 13] uri="sip:test.3gpp.com",

username="001010123456789@test.3gpp.com",

response="",realm="test.3gpp.com",

nonce=""

[ Line 14] Expires: 7200

[ Line 15] Supported: path

[ Line 16] Allow: INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,REFER,PRACK,INFO,MESSAGE,OPTIONS

This REGISTER clip highlights From, To, CSeq, Call-ID, Via, Max-Forwards, Contact, Route, P-Access-Network-Info, Content-Length, Authorization, Expires, Supported, and Allow. The specific capability parameters to inspect are Contact, reg-id, +g.3gpp.csi.smsip, and +g.3gpp.icsi-ref; these values advertise SMS over IMS and MMTel service support.

[Line 8] According to GSMA IR92,

The UE must include an IMEI URN (see 3GPP TS 23.003 section 13.8) in the "+sip.instance" header field parameter (Instance ID) of the Contact address.
The UE must include IMS Communication Service Identifier (ICSI) value used to indicate the IMS Multimedia Telephony service, that being urn:urn-7:3gpp-service.ims.icsi.mmtel per 3GPP TS 24.173, using procedures as defined in section 5.1.1.2.1 of 3GPP TS 24.229. If the UE supports SMS over IP (see section 2.5 and A.7), it must include feature tag used to indicate SMS over IP service, that being +g.3gpp.smsip as defined in section 5.3.2.2 of 3GPP TS 24.341

Example 3 : UE Capability - IMS over SMS and VoLTE

This example extends the Contact capability set to include both SMS over IMS and VoLTE/MMTel related feature tags. It is useful when checking whether the UE is advertising voice, video, SMS, RCS telephony, and instance identity information in a single REGISTER.

Route: <sip:[2001:0:0:1::2]:5060;lr>

Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK

Expires: 600000

Authorization: Digest username="001010123456789@test.3gpp.com",realm="TestIMS.com",

nonce="fn3iiH1LnWqCtFyPUD8qzYxfiiVavYAAmfcxByxmhBg=",algorithm=AKAv1-MD5,

uri="sip:test.3gpp.com",response="9f17517adee640b8895dda33b336f071",

qop=auth,nc=00000002,cnonce="dsf232sun2299674910xyx",

opaque="bbedd3dd5f884860b741b03d36b430ea"

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0010100010000001

Contact: <sip:+11234567890@[2001:0:0:1::1]:5060>;

+g.3gpp.smsip;

+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;

This SIP message clip highlights the following parameters: Route, Contact, Authorization, Expires, P-Access-Network-Info, Allow, nonce, response, realm, qop, algorithm, opaque. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

+g.gsma.rcs.telephony="cs,volte";

+sip.instance="<urn:gsma:imei:99000493-686661-0>"

From: <sip:+11234567890@test.3gpp.com>;tag=1334507655

To: <sip:+11234567890@test.3gpp.com>

Call-ID: 266901530@2001:0:0:1::1

CSeq: 4 REGISTER

Max-Forwards: 70

Via: SIP/2.0/UDP [2001:0:0:1::1]:5060;branch=z9hG4bK459934981smg;transport=UDP

Content-Length: 0

This REGISTER clip highlights Route, Allow, Expires, Authorization, P-Access-Network-Info, Contact, From, To, Call-ID, CSeq, Max-Forwards, Via, and Content-Length. The capability parameters inside Contact are the main point: +g.3gpp.smsip indicates SMS over IMS, +g.3gpp.icsi-ref identifies MMTel service, video indicates video capability, +g.gsma.rcs.telephony indicates CS/VoLTE telephony support, and +sip.instance carries the UE instance identity.

Example 4 : Authentication Information

This example is mainly about the Authorization header after the UE has received a 401 challenge. The important check is whether the UE used the challenge values correctly and generated a response value that the network can verify.

Following is a REGISTER which is sent after 401 chalenge. so it carries all the detailed parameters for Authentication as in [Line13]

[ Line 1 ] REGISTER sip:test.3gpp.com SIP/2.0

[ Line 2 ] From: <sip:+11234567890@test.3gpp.com>;tag=3671736441

[ Line 3 ] To: <sip:+11234567890@test.3gpp.com>

[ Line 4 ] CSeq: 450510775 REGISTER

[ Line 5 ] Call-ID: 3671736255_186872264@2001:0:0:1::3

[ Line 6 ] Via: SIP/2.0/UDP [2001:0:0:1::3]:5060;branch=z9hG4bK788602866

[ Line 7 ] Max-Forwards: 70

[ Line 8 ] Contact: <sip:+11234567890@[2001:0:0:1::3]:5060>;

reg-id=1;

+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

+g.3gpp.csi.smsip

[ Line 9 ] Route: <sip:[2001:0:0:1::2]:5060;lr>

[ Line 10] P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010100010000000

[ Line 11] Content-Length: 0

[ Line 12] Authorization: Digest

[ Line 13] username="001010123456789@test.3gpp.com",

realm="test.3gpp.com",uri="sip:test.3gpp.com",

qop=auth,

nonce="DtIe00txvoZUGvYmjgX98eAPJNjx3IAADsM84A8kWPE=",

nc=00000001,

cnonce="3671736221",

algorithm=AKAv1-MD5,

response="013e2a5d762d4d86e56112c0d41379f5",

opaque="3c45b78d08f348459596ea2f6d316a42"

[ Line 14] Expires: 7200

[ Line 15] Supported: path

[ Line 16] Allow: INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,REFER,PRACK,INFO,MESSAGE,OPTIONS

This authenticated REGISTER clip highlights Contact, Route, P-Access-Network-Info, Authorization, Expires, Supported, and Allow in addition to the normal From, To, Call-ID, CSeq, Via, and Max-Forwards headers. In Authorization, the key parameters are username, realm, uri, qop, nonce, nc, cnonce, algorithm, response, and opaque; response is the calculated proof, while nonce, nc, cnonce, qop, and algorithm define how that proof is generated.

[Line 8] According to GSMA IR92,

The UE must include an IMEI URN (see 3GPP TS 23.003 section 13.8) in the "+sip.instance" header field parameter (Instance ID) of the Contact address.
The UE must include IMS Communication Service Identifier (ICSI) value used to indicate the IMS Multimedia Telephony service, that being urn:urn-7:3gpp-service.ims.icsi.mmtel per 3GPP TS 24.173, using procedures as defined in section 5.1.1.2.1 of 3GPP TS 24.229. If the UE supports SMS over IP (see section 2.5 and A.7), it must include feature tag used to indicate SMS over IP service, that being +g.3gpp.smsip as defined in section 5.3.2.2 of 3GPP TS 24.341

[Line 13] This line is the most important part in REGISTER for Authentication.

username : The first thing you have to pay attention is 'username'. This is a private ID for the user. This ID would be stored in IMPI field of USIM/ISIM (refer to User Identity page) or UE's internal configuration(in case of the UE at early development stage). Since the IMS Server Authentication center identifies UE with this 'username' field, if this username does not match the username in Authentication center, the server would send '404 Not Found' error message.
realm : This is the domain name of the authentication center.
nonce, response : These are values for authentication that are calculated by UE. These values should match the value calculated by Authentication Center.

Example 5 : IPSec Information

This example shows REGISTER content used when IMS security agreement is required. The message advertises the UE security capability and the candidate IPSec algorithms and ports that the P-CSCF can select for protected SIP signaling.

[ Line 1 ] REGISTER sip:test.3gpp.com SIP/2.0

[ Line 2 ] f: <sip:001010123456789@ims.mnc246.mcc081.3gppnetwork.org>;tag=2922225

[ Line 3 ] t: <sip:001010123456789@ims.mnc246.mcc081.3gppnetwork.org>

[ Line 4 ] CSeq: 2922203 REGISTER

[ Line 5 ] i: 2922206_181933240@2001:0:0:1::3

[ Line 6 ] v: SIP/2.0/TCP [2001:0:0:1::3]:5060;branch=z9hG4bK3941737881

[ Line 7 ] Max-Forwards: 70

This SIP message clip highlights the following parameters: Max-Forwards, v. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

[ Line 8 ] m: <sip:001010123456789@[2001:0:0:1::3]:5060>;

+sip.instance="<urn:gsma:imei:35425006-000655-0>";

+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

+g.3gpp.smsip

[ Line 9 ] Route: <sip:[2001:0:0:1::2]:5060;lr>

[ Line 10] l: 0

[ Line 11] Authorization: Digest

[ Line 12] uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",

response="",realm="test.3gpp.com",nonce=""

[ Line 13] Expires: 600000

[ Line 14] Require: sec-agree

[ Line 15] Proxy-Require: sec-agree

[ Line 16] k: path,sec-agree

[ Line 17] Allow: INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,REFER,PRACK,INFO,MESSAGE,OPTIONS

This SIP message clip highlights the following parameters: Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

[ Line 18] Security-Client:

ipsec-3gpp; alg=hmac-md5-96; ealg=des-ede3-cbc; spi-c=799251570; spi-s=1387593208;

port-c=8006; port-s=8906,

ipsec-3gpp; alg=hmac-md5-96; ealg=aes-cbc; spi-c=799251570; spi-s=1387593208;

port-c=8006; port-s=8906,

ipsec-3gpp; alg=hmac-md5-96; ealg=null; spi-c=799251570; spi-s=1387593208;

port-c=8006; port-s=8906,

ipsec-3gpp; alg=hmac-sha-1-96; ealg=des-ede3-cbc; spi-c=799251570; spi-s=1387593208;

port-c=8006; port-s=8906,

ipsec-3gpp; alg=hmac-sha-1-96; ealg=aes-cbc; spi-c=799251570; spi-s=1387593208;

port-c=8006; port-s=8906,

ipsec-3gpp; alg=hmac-sha-1-96; ealg=null; spi-c=799251570; spi-s=1387593208; port-c=8006;

port-s=8906

This IPSec REGISTER clip highlights Request-URI, From, To, CSeq, Call-ID, Via, Contact, Route, Authorization, Expires, Require, Proxy-Require, Supported/k, Allow, and Security-Client. The Security-Client parameters are the main focus: ipsec-3gpp identifies the mechanism, alg and ealg list integrity and encryption algorithms, spi-c and spi-s identify the client/server SPIs, and port-c and port-s identify the protected client/server ports.

[Line 8] According to GSMA IR92,

The UE must include an IMEI URN (see 3GPP TS 23.003 section 13.8) in the "+sip.instance" header field parameter (Instance ID) of the Contact address.
The UE must include IMS Communication Service Identifier (ICSI) value used to indicate the IMS Multimedia Telephony service, that being urn:urn-7:3gpp-service.ims.icsi.mmtel per 3GPP TS 24.173, using procedures as defined in section 5.1.1.2.1 of 3GPP TS 24.229. If the UE supports SMS over IP (see section 2.5 and A.7), it must include feature tag used to indicate SMS over IP service, that being +g.3gpp.smsip as defined in section 5.3.2.2 of 3GPP TS 24.341

Example 6 : UnRegist

This example shows how a normal REGISTER becomes an unregistration request. Most headers still identify the UE and registration context, but the Expires value changes the meaning of the request.

There is no specific message for UnRegistration. SIP uses 'REGISTER' message for Unregistration as well. Just setting 'Expires' field to be 0 perform SIP Unregistration.

f: <sip:+11234567890@test.3gpp.com>;tag=589636628

t: <sip:+11234567890@test.3gpp.com>

CSeq: 589636509 REGISTER

i: 589636508_2363003488@10.133.202.46

v: SIP/2.0/UDP 10.133.202.46:5060;branch=z9hG4bK428556305

Max-Forwards: 70

m: <sip:+11234567890@10.133.202.46:5060>

P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800001FFFFFFF

Expires: 0

l: 0

Authorization: Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",realm="test.3gpp.com",nonce="",

Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",

realm="test.3gpp.com",nonce=""

This unregistration REGISTER clip highlights Request-URI, From/f, To/t, CSeq, Call-ID/i, Via/v, Max-Forwards, Contact/m, P-Access-Network-Info, Expires, Content-Length/l, and Authorization. The key parameter is Expires: 0, which requests removal of the registration binding; Contact identifies which binding is being removed, and Authorization identifies the subscriber context.