Author: GUO Zhenhua @ TELECOM ParisTech & Alcatel-Lucent France
Nov. 5th 2008
All rights reserved
百思博客8Z5^6^u k6A
-- This document is a summary of what I’ve seen in IMS textbooks, related specifications and enterprise test examples, for IMS beginners who feel interested to understand the terms, and the details concerning all aspects of IMS registration messages. If you find any fault and suggestion, plz contact me.
.@NF"tV#yV0
"IMS - IP Multimedia Concepts and Services (second edition)" by Miikka Poikselka etc.
3GPP/IETF spec
百思博客&F`&Zi+R
1. Introduction
Generally speaking, the REGISTER request is for the purpose of binding the IP@ that the user is using with the user’s SIP URI and to periodically refresh the binding, so that the following SIP messages can easily communicate using URIs, no matter what terminal, what IP@ is being used by the end user.
百思博客 rvuYX 2. Method of reading main information in REGISTER message:
(binding)
百思博客H v8q1/Tk0m
3. Key Information contained in the REGISTER message
1) Main headers in REGISTER:
Request-URI – from here we know the address of the registrar, domain name of the home network of the user, it is read from the ISIM.
From – from here we know the registration is performed by whom, usually in REGISTER the From header is the same as the To header, because we are always doing a “first-party” registration.
To – from here we know which URI is going to be registered and this URI will be bund with the IP@ in the Contact header .
Contact – this IP@ is going to be bund with the SIP URI in the To header , and is assigned during the establishment of the PDP context; the expire time is usually a large value and set by the UE side to last the binding of the SIP URI and IP@, it can be modified by the 200OK response or other messages from the server side.
Via – set up by every SIP entity, which puts its address to its own Via header on the route, to indicate where the response should be sent; this ensures that all responses to the request will be routed back to the UE, as UE and all other SIP entities have put theirs IP@ in this header; the transport protocol depends on the size of REGISTER message, if not exceed 1.3Kb then UDP is used, otherwise TCP is used; the branch parameter identifies the transaction and is unique.
* Important conclusions: Contact header = @ for receiving incoming requests , Via header = the route for responses , Route header = the known route for outgoing requests .
2) Other routing-related headers in REGISTER: (Via – is one of them). [RFC3608]
Route – for routing of requests; it is set up by request-originating UE or by CSCFs, which put the next hop in the initial request, or copy the Record-Route header to it in the subsequent requests.
Record-Route – for recording the Route header entries for subsequent requests within one dialog; it is set up by CSCFs, which put their @s if they need to receive subsequent requests.
Service-Route – (in originating case, indicate the Route header entries) for the UE to know the direct route to the S-CSCF and thereby pass no longer I-CSCF in the following initial requests other than REGISTER in one dialog; it is set up by S-CSCF, which sends it back to the UE in 200OK, and stored by the UE.
Path – (in terminating case, collect the Route header entries) for the S-CSCF to know the @ of the P-CSCF; it is set up by the P-CSCF, which adds itself to the Path header and sends it to the S-CSCF and stored by S-CSCF.
4. REGISTER message process at each SIP entity
<!--[if !supportEmptyParas]-->
UE (-> P-CSCF)
Construct the initial request original message as we most often see.
- Via : UE@;
- Contact : UE@;
- Route : P-CSCF@;
- Max-Forword : 70 (classic value)
P-CSCF (-> I-CSCF)
- Via : P-CSCF@, UE@;
- Route : empty;
- Path : P-CSCF@;
- Max-Forword: 69 (when we see 69, it must be sent from P-CSCF to somewhere).
I-CSCF (-> S-CSCF)
- Via : I-CSCF@, P-CSCF@, UE@;
- Route : S-CSCF@;
- Max-Forword: 68.
[Usually we can’t see this message because the I-CSCF and S-CSCF always work in one single machine.]
S-CSCF (-> I,P-CSCF, UE)
401 Unauthorized response.
Subsequent REGISTER request
UE (-> P,I,S-CSCF)
- Construct the second REGISTER request with authentication information (which will be routed exactly the same way as the initial request).
S-CSCF
When the authentication information is correct, the S-CSCF at this time
- Register the UE (this means that it create a binding for the URI in To header and IP @ in Contact header ; this binding lasts for the expire time set in the Contact header by the UE; otherwise the S-CSCF can decide to reduce this value and send it in the 200Ok response);
- Update the user information in the HSS, to indicate that the UE is registered;
- Download user profile to S-CSCF;
- Path header: P-CSCF @;
- Register to AS on behalf of the UE (as a third-party);
- Send 200OK response, add a to-tag to the To header, and add a Service-Route header to avoid the following requests from this UE pass the I-CSCF.
I,P-CSCF, UE
- 200 OK traverses them because S-CSCF put their @s in the Via header list just as received; (in fact the purpose of the Via head is at this point)
- When receiving the 200 OK, they remove themselves from the Via header list and forward the message.
- The UE will store the Service-Route header . Whenever it sends any initial request other than REGISTER it will include the @s in the Service-Route header in the Route header and include the P-CSCF @ in the topmost Route header .
5. Security Mechanism (Authentication + SA)
Security of SIP registration = Authentication between user and network
+ SA between UE and P-CSCF
Digest Access Authentication [RFC3310]
HTTP Digest, though not recommended by 3GPP, is simpler and usually in use by many ALU-IMS or other companys’ products.
Because HTTP digest (IETF) is used with SIP while IMS is part of 3GPP structure, in order to achieve 3GPP AKA based authentication, we choose to implement 3GPP AKA on HTTP digest SIP message (parameters in REGISTER).
[RFC3310] defines how 3GPP AKA parameters are mapped to HTTP digest authentication.
* The normal HTTP digest conception, is just like what we usually do to access certain web content on Internet, e.g. login on a web site or email, or forum etc.
In initial REGISTER request:
Authorization header :
- Authentication scheme : “Digest” (only this value);
- Username: set to user’s IMPI (IMPI )
- Realm : set to the home domain of user
- Authentication URI : set to the home domain of user
- Nonce: empty
- Response: empty
P-CSCF will add to this request Integrity-protected = “no”.
3X+BW$V#/O-RGV0 In 401Unauthorized response (S-CSCF challenges the UE):
WWW-Authentication header:
- Authentication scheme: “Digest” (only this value);
- Realm: copy from request
- Nonce : contains RAND+AUTH parameter (random challenge + network authentication token);
- Algorithm : set to “AKAv1-MD5”, which identifies the 3GPP AKA mechanism;
- IK : contains Integrity Key
- CK : contains Ciphering Key
IK and CK will be stored and removed by P-CSCF before sent to UE.
In subsequent REGISTER request (UE responses to the challenge):
Authorization header : (new value)
- Nonce : copy from 401 response;
- Response : RES, derived by the ISIM from RAND + shared key, which answer the S-CSCF challenge.
P-CSCF will add to this request Integrity-protected = “yes” (because ISIM also calculate IK, add it in Response, and send to P-CSCF).
<!--[if !supportEmptyParas]-->
S-CSCF compares the RES and XRES, if equal, send 200OK
IPsec SA (Security Association) [3GPP TS 33.203] [RFC2401]
Actually, to manage ports of the UE and the P-CSCF. One of the possible security mechanisms (however, for the current 3GPP R5/R6, it’s the only mechanism).
Initial registration:
- The set of SAs begin after the UE receive the 401 response.
- A set of SAs (4 SAs) contains 4 ports: uc1, us1, pc1, ps1;
1° uc1 -> ps1
request UE -> P-CSCF
2° us1 <- pc1
response P-CSCF -> UE
3° us1 <- pc1
request P-CSCF -> UE
4° uc1 -> ps1
response UE -> P-CSCF
- These ports are negotiated between UE and P-CSCF during initial registration;
-The set of SAs needs a shared key other than the shared key that is only between UE and HSS; So the IK is used as the shared key for the set of SAs (IK is contained in the 401 response);
- When sending the 200OK response, the P-CSCF updates the lifetime of the set of SAs to “expire time value in contact header + 30”.
Re-authentication (be careful the difference with re-registration):
- Re-authentication can be requested by the S-CSCF during any re-registration procedure, and then a new set of SAs must be set up between the UE and the P-CSCF (with the old set of SAs based on initial request still there), because IPsec SAs are based on IK, and IK changes during each re-authentication.
- Two new ports are then involved for the new set of SAs: uc2, pc2;
- But the UE never needs to handle more than two sets of SAs at the same time.
Method to read the ports:
- The UE will set the us1 in the Contact header of every request (including initial REGISTER) and in the Via header of every requests (except the initial REGISTER);
- The UE will set the ps1 in the Route header in every initial request.
- The P-CSCF set the ps1 in the Record-route header.
In initial REGISTER request:
- If we can see the Security-Client header , it means the UE want to establish a set of IPsec SAs, and we can see the uc1 and us1 value;
- If the port value is set to us1 other than 5060 in the Contact header , the UE is expecting all incoming request to be routed to this protected port us1 ;
- If no port is given in the Via header , UE will wait the response to this initial REGISTER on the unprotected port 5060;
- If no port is given in the Route header , this initial REGISTER will be sent to the unprotected port 5060 of P-CSCF;
In 401Unauthorized response:
- If we can see the Security-Server header , it means the P-CSCF is going to establish the set of Ipsec SAs, and we can see the pc1 and ps1 value;
- Then the temporary set of SAs is established.
In second REGISTER request:
- us1 can be seen in Via header (now expects all responses to this REGISTER from P-CSCF on us1 ) and Contact header (now expect all incoming initial requests from P-CSCF on us1 );
- ps1 can be seen in Route header (send this request to P-CSCF already on ps1 ).
In re-authentication:
- Both the UE and the P-CSCF change their protected client port only (add uc2 and pc2 );
- us1 and ps1 remain unchanged (because the change of us and ps will cause a lot of problems).
3) Sip-Sec-Agree (SIP Security Mechanism Agreement)
Sip-Sec-Agree is for UE and P-CSCF (only in the messages between them) to negotiate a common security mechanism for use between them (IPsec might not remain the only one). [RFC3329]
- Require header : sec-agree
- Proxy-Require : sec-agree (indicate that P-CSCF must support the Sip-Sec-Agree)
- The UE advertises the mechanisms it supports in Security-Client header of the initial REGISTER request, e.g. Digest and IPsec.
- The P-CSCF, if doesn’t support Sip-Sec-Agree procedure, sends back a 420 Bad Extension response, otherwise it sends back the list of supported mechanisms with preference (q-value) in the Security-Server header in the 401 Unauthorized response, e.g. IPsec and TLS.
- The UE, on receiving the 401 response, begins to set up the chosen security mechanism, e.g. the set of IPsec SAs. Then over these SAs, it sends out the second REGISTER request, in which it copies the Security-Server header from the 401 response into the Security-Verify header , and sends the same content of the Service-Client header as in the initial REGISTER request (this is to guarantee that the Sip-Sec-Agree information remain unchanged).
* Important: No mater initial request or subsequent ones, the P-CSCF always removes the SA-related headers (Require, Proxy-Require, Security-Client, Security-Verify ) before sending them to I/S-CSCF.
4) Early IMS security
There are 9 cases in all, depending on the early/full/both support of UE and network. (For UE, if no “sec-agree” option is included in the Require header & Proxy-Require header , then only early IMS security is supported by UE).
1° UE supports both full/early IMS security, P-CSCF support only early IMS security
Sends normal REGISTER with - IMPU taken from ISIM
- Authorization header , Require header , Proxy-Require header , Security-Client header etc.
Unsupported : sec-agree
(The P-CSCF doesn’t support Sip-Sec-Agree procedure. Early IMS security has to be applied).
- New REGISTER without Authorization header , Require header , Proxy-Require header , Security-Client header etc.
- IMPU derived from USIM, even if the UE is equipped with ISIM (pay attention here ).
- Check the MSISDN is correlated with the IMSI;
- Check the IP@ is the one assigned to this MSISDN by GGSN;
- 200OK is sent (authentication finished).
<!--[if !supportEmptyParas]-->
2° UE supports only early IMS security, network support only full IMS security
- New REGISTER without Authorization header , Require header , Proxy-Require header , Security-Client header etc.
- IMPU derived from USIM, even if the UE is equipped with ISIM (pay attention here ).
Require : sec-agree
6. Following SUBSCRIBE to registration-state event information
<!--[if !supportEmptyParas]-->
1) User identities in initial REGISTER request and 200OK response
[ISIM : IP Multimedia Service Identity Module]
[USIM : Universal Subscriber Identity Module]
[IMSI : International Mobile Subscriber Identifier]
[IMPI : Private User Identity]
[IMPU : Public User Identity]
One user might have many a public user identity (IMPU).
In the initial REGISTER request
Three kinds of information are read from ISIM application on the UICC if the UE is equipped with ISIM application (otherwise, it will derive all these information from the USIM application on the UICC, btw, it is simple to derive IMPI from IMSI on USIM):
1° The IMPI is used for authentication, to fill the Username parameter in Authentication header ;
2° The IMPU is used for registration, to fill the From header and To header ;
3° @ of SIP registrar, to fill the request-URI , the Realm parameter and Authentication URI parameter in the Authentication header .
<!--[if !supportEmptyParas]--> <!--[endif]-->
In the 200OK response to REGISTER
P-Associated-URI header: lists all the associated IMPUs (all SIP URIs and tel URLs). The first URI is default IMPU and always a valid, registered one. (P-header: Private Header Extensions of SIP for 3GPP).
To know more about the registration status of other IMPUs assigned to the same user, the UE and the P-CSCF will separately and immediately perform. the subscription to the user’s registration-state event information, soon after receiving the 200OK of REGISTER request.
2) UE’s SUBSCRIBE request (it is still in the same dialog with the REGISTER)
UE->P-CSCF
Request-URI : IMPU of the requested user, whose registration-state info is required
To : the same meaning with request-URI header;
P-Preferred-Identity : the same meaning with request-URI header and To header;
(This value is either the explicitly registered IMPU in the initial REGISTER, or the default IMPU in the P-Associated-URI header in 200OK response, it’s usual that the two are the same, if no temporary IMPU is used when there’s ISIM application);
From : the IMPU of the subscribing user;
Event : reg (the event name for registration-state event information)
Accept : e.g. “reginfo+xml” means that only the registration-state information in XML can be processed by the UE;
Route : P-CSCF@, S-CSCF@ (it forces the SUBSCRIBE request to pass no I-CSCF; the S-CSCF@ is copied from the Service-Route header in the 200OK response; the P-CSCF@ is added by the UE);
Expire : the same as that in the initial REGISTER;
Contact : the same as that in the second REGISTER after 401Unauthorized response.
P-CSCF->S-CSCF
Route : S-CSCF@
P-Asserted-Identity : the same as the P-Preferred-Identity header in the SUBSCRIBE request if it is a valid IMPU of the user;
S-CSCF
- Check whether the requested user (of the P-Asserted-Identity header ) is registered;
- Check whether the subscribing user has the rights to have the registration-state info of the requested user; usually, we are subscribing our own registration-state info, so it is allowed.
- If both is OK, the S-CSCF sends 200OK to UE to indicate the subscription is successful, generate an XML including the current registration-state info for all the IMPUs that are associated with the requested user and send it in a NOTIFY request to the subscribing user. (200OK and NOTIFY are send at the same time, so it is possible that NOTIFY even arrives earlier than 200OK to SUBSCRIBE)
3) P-CSCF’s SUBSCRIBE request (this will be another dialog with the REGISTER)
P-CSCF->I/S-CSCF
Request-URI header and To header : the IMPU of requested user;
Event header , Expire header and Accept header are the same as the UE’s SUBSCRIBE;
P-Asserted-Identity : P-CSCf@ (because P-CSCF is a trusted entity, it puts its address directly here);
From : P-CSCF@ (because here P-CSCF is the subscribing entity)
Route : empty (P-CSCF doesn’t store the Service-Route header , so it has to start from scratch and this routing is as complicated as the initial REGISTER (need DNS, HSS etc.) and passes I-CSCF of course)
<!--[if !supportEmptyParas]-->
<!--[if !supportLists]-->· <!--[endif]-->Notice: because the P-CSCF’s subscription is another dialog, between the P-CSCF and the S-CSCF, even the UE and P-CSCF are subscribing the same registration-state info, the S-CSCF need to generate separate NOTIFY requests to send to them. Pay attention that the bodies of NOTIFY are the same, while the headers of NOTIFY are different.
4) The NOTIFY requests from S-CSCF
From : the IMPU of the requested user
To : 1° the IMPU of the subscribing user when sent to UE; 2° the P-CSCF@ when sent to P-CSCF.
Subscription-State : the summary of the subscription-state (Attention! Not the registration-state, the registration-state can only be seen in the message XML body)
XML Body : registration-state information (hierarchical as follows):
* Pay attention to the differences among the 3 “state” attributes in the 3 layers
Root element “reginfo” : registration-state information associated with one user. Attributes:
“xlmns” : points to the URN (uniform. resource name) that defines the XML document and namespace.
“version” : starts with 0, the version of registration-state information sent to the same subscriber.
“state” : full / partial (a full list of all the AORs relate to the requested user (version 0), or only include changed information since last notification (version 1,2,3…))
Sub-element “registration” : includes information about exactly one URI. So it is possible to have several “registration” sub-elements under the “reginfo”. Attributes:
“AOR” (@ of Record): one associated URI (IMPU) for this user;
“id” : identifies the “registration” from all the others;
“state” : whether this URI is active / terminated / init (registered / de-registered / being registered).
Sub-element “contact” : includes information about an address that has been registered/de-registered for the URI in the “registration” (but usually if de-registered there is no more further info). Attributes:
“id” : identifies the “contact” from all the others;
“state” : active / terminated (to indicate whether the binding between the URI in the “registration” and this @ is on);
“event” : registered / created / refreshed / shortened / deactivated / probation / unregistered / rejected (the event that cause the last change in the “contact” “State” value).
registered: successful explicitly registered (explicit binding).
created: successful implicitly registered (automatic binding).
refreshed: explicitly/implicitly re-registered.
shortened: to trigger a network-initiated de-registration (in this case, “Expire” attribute is a must).
deactivated: the binding is removed by a network-initiated de-registration.
probation: network can de-register the user and request her to send a new initial registration after a certain time (in this case, “Retry- after” attribute is a must).
unregistered: explicitly unregistered.
rejected: not allow this user to binding the specific contact.
7. Re-registration and re-authentication
1) User-initiated re-registration (no re-authentication)
One most usual example is that when the expiry time is due and so the UE initiates a new registration in the same way as an initial registration procedure.
2) Network-initiated re-registration (with re-authentication)
One example is that the home operator wants to perform. a random re-authentication, then the S-CSCF may reduce the expiry time that the UE has proposed in Contact header.
As the UE has done the inscription to the registration-state event package, it receives NOTIFY request from the S-CSCF which makes it to update the registration expiry time information.
Network-initiated re-authentication NOTIFY
In this NOTIFY request body
reginfo: version > 0, state = “partial”;
registration: unchanged;
contact: event = “shortened”, expires = new value.
,]~:e8T!f5tv/`3|ly0 Then after half the new expiry time it sends out the REGISTER request to re-registration.
<!--[endif]--> O{L'F)y"j f7l;b0 8. De-registration
<!--[if !supportEmptyParas]-->
1) User-initiated de-registration (with REGISTER request)
One example is that the user switch off her phone.
UE->P/I/S-CSCF:
- “expires” in the Contact header is set to 0;
- Route in the same way as the initial REGISTER, not following the stored Service-Route header.
S-CSCF->P-CSCF, UE
- Send back the 200OK response to the REGISTER to the user’s UE;
- Generate the NOTIFY request to all subscribers of the registration-state information of the user:
Subscription-State : terminated (here means the subscriptions are terminated, not the registration)
The body of NOTIFY tells the registration-state information:
reginfo: version > 0, state = “partial”;
registration: state = “active”/ “terminated” (depends on whether the URI are still binding to other IP@);
contact: state = “terminated”, event = “unregistered”.
S-CSCF->P-CSCF
Send to P-CSCF a separate request (different header) but contains the same body.
2) Network-initiated de-registration (only NOTIFY)
Examples are when the S-CSCF needs to shut down or when the user’s credit charge is used out.
S-CSCF->P-CSCF, UE
Subscription-State : terminated (here means the subscriptions are terminated, not the registration)
The body of NOTIFY tells the registration-state information:
reginfo: version > 0, state = “partial”;
registration: state = “terminated” (only this value);
contact: state = “terminated”, event = “deactivated” (only these values).
S-CSCF->P-CSCF
Send to P-CSCF a separate request (different header) but contains the same body.
9. SIP Compression Negotiation [RFC3486]
For UE and P-CSCF to negotiate whether to apply SigComp (Signalling Compression).
- SigComp state creation will only be done after the IP SAs are established (after 401 response).
- “comp” parameter is introduced in SIP request and response.
For UE:
comp=SipComp in Via header : UE is willing to receive response to this requests compressed;
comp=SipComp in Contact header : UE is willing to receive incoming requests compressed within this dialog;
For P-CSCF:
comp=SipComp in Record-Route header : P-CSCF is willing to receive subsequent requests within this dialog compressed;
comp=SipComp in Via header : P-CSCF is willing to receive response to this requests compressed;
10. Other information [RFC3455]
<!--[if !supportEmptyParas]-->
1) Access and location information
P-Access-Network-Info header : over which access technology the UE is attached to IMS; the CGI (Cell Global ID) tell the location of the user; included by the UE;
P-Visited-Network-ID header : the roaming network of UE; included by the P-CSCF; S-CSCF will use it to check the roaming agreement with this visited network.
2) Charging information
P-Charging-Vector header : ICID (IMS Charging ID) value; created by the P-CSCF; S-CSCF will store ICID and perform. the charging procedures.
