4G to IMS call flow – Register to IMS – part 6

Posted: September 11, 2010 in technical
Tags: , , , , , , , , , , , , , , , , , , ,

Hey there. ‘ve got back from holiday, live and kicking !!! 😀

19. Register – message created by the UE – described in Step 17 – windancersth.wordpress.com/2010/08/29/4g-to-ims-call-flow-–-register-to-ims-–-part-4.html

The Register message is then forwarded by the local / visited network (in this case) P-CSCF to the remote/home-network’s I-CSCF.

Here is the (big) picture again, in case somebody forgot it – and we are at Step 19. Register:

4G-IMS

And here is how this message should look like after crossing from the visited network to the home network domain:

REGISTER sip:registrar1.home.net SIP/2.0
Via:SIP/2.0/UDP pcscf1.visited.net;branch=z9hG4bKoh2qrz,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 69
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
Path: <sip:term@pcscf1.visited.net;lr>
Require: Path
P-Visited-Network-ID: “Cristina Visited  Network”
P-Charging-Vector: icid-value=”1234bc9876e”
From: <sip:alice_public@home.net>;tag=s8732n
To: <sip:alice_public@home.net>
Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”alice_private@home.net”,realm=”registrar1.home.net”, nonce=””,uri=”sip:registrar1.home.net”, response=””,integrity-protected=”no”
Cseq: 1 REGISTER
Supported: path
Content-Length: 0
As you may have already noticed, the bolded parts are new or changes from the previous REGISTER message in Step 17.
1. The Method is the same: Register
2. The Via header changed: the visited network P-CSCF added its address in the path, before the address of the UE. Basically, when each sip-aware device in the way processes this message, it will add its own address before the other ones, not deleting anyone, so there will be a looong lines of Vias. But, when the reply comes back to this UE, each device will be in the path (in reverse order, of course) and it will remove its address from the path, so that the Via lines decrease and remain only with the UE’s address in the end.
So, now our Via header has first the URI of the P-CSCF in the visited network, then the URI of the UE.
3. Max-Forwards value, of course, decreases, from 70 forwards we only have 69 now, as our message has already been forwarded once so far.
4. Path is new. The visited P-CSCF puts here its URI in order to make sure every message headed to this UE will be forwarded via this device, the visited P.
Now, about that lr thinggie. LR stands for loose routing. Basically loose routing means (as per RFC 3261) that the proxies in a SIP message path don’t have to rewrite the Request-URI of the next hop in order to be able to route the SIP message till the destination. They simply leave this URI with the address of the destination and only look at the Router header for routing purpose. And there is also a thinggie called strict routing – which does the opposite, changing and changing the Request-URI at each step. The cool guys from IPTEL describe these concepts briefly and really nice on their site: http://www.iptel.org/sip/intro/scenarios/rr/strict_vs_loose .
5. At this point, our P-CSCF has put its URI in the Path, in order for every SIP message destined to this UE to pass through it, because otherwise that message will never reach this UE. What it needs to do now is to make sure the other SIP guys also understand this Path requirement and make sure they comply. So, it uses the Require header to indicate to the other fellow SIP proxies that it means business with this Path thing and it really must be in the path of the SIP messages. Technically, this assures that, if any proxy on the way does not support Path, it will have to send a response back stating it cannot comply to this requirement. The response code is 420 and it will also include a Unsupported header which will have the value “Path”.
6. P-Visited-Network-ID: “Cristina Visited  Network”
As I was also saying previously, the P-Visited-Network-ID is included by the visited network P-CSCF in order to tell the home network about itself. This information is important for the home network, because based on this value here, the HSS will verify the existence of a roaming agreement between the home network of the UE and the visited network where it is located in the moment of the IMS Registration.
7. P-Charging-Vector: icid-value=”1234bc9876e”
This is populated by the P-CSCF with a globally unique value. The P-Charging-Vector is described in RFC 3455 – section 4.6. The same RFC describes also the P-Visited-Network-ID and other 3GPP extensions to the SIP protocol, in order to accommodate it to the 3GPP – IMS requirements. The actual name of the RFC 3455 is Private Header (P-Header) Extensions to the Session Initiated Protocol (SIP) for 3rd-Generation Partnership Project (3GPP).
** Now we are in the Home Network. We have our home I-CSCF (Interrogating) which has just received the Register message from the visited P-CSCF. It looks at it message, but has no idea whether the HSS has already registered or not this UE and, as a consequence, whether or not the HSS has already assigned a S-CSCF (Serving) to this UE. So, first of all, it creates a Diameter session to the HSS to clarify things up.
Ah, BTW, this Diameter thinggie is a real pain in the rear :). It has a bunch of ramifications from the base protocol and I will only list some of them. To be honest, I haven’t yet got the chance to closely study Diameter, but I hope to come back soon with more details in this. I believe here the WIKIPEDIA is a good start up point to have the listing:

20. Diameter UAR
As I was saying there A LOT of Diameter standards. But the precise one used here in SIP-IMS authorization belongs to RFC 4740 – Diameter Session Initiation Protocol (SIP) Application.
Message 20 is called Diameter Cx-Query or Diameter UAR – User-Authorization-Request and it is sent from the I-CSCF to the HSS, via the Cx interface. The I-CSCF makes this request in order to obtain information about the registration status of this Subscriber. As the I-CSCF proxies to not store any UA (User Agent) status on their own, they need to contact the HSS each time to see whether any S(Serving)-CSCF has already been allocated to this User Agent. As in our case this is a first time registration, the UA doesn’t have any S allocated previously, but the I does not know that at this point in time. So, the I sends the HSS in this UAR message the private user identity of the UA (alice_private@home.net), public user identity (alice_public@home.net) and the visited domain identifier (Cristina Visited Network).
As per RFC 4740 – section 8.1, this UAR command would look something like this:
       <UAR> ::= < Diameter Header: 283, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Visited-Network-Id ]
                 [ SIP-User-Authorization-Type ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]
21. Diameter UAA
The HSS analyzes the UAR command, matches the information about the UA and the visited network, and it decides whether this is its UE or not, whether it can authorize this access to the network or not, which S-CSCF capabilities to allocate to it and, also very important, if this operator has a roaming agreement with the specified visited network and if so, in which terms. If this were not a first register message, so this UE would already have allocated an S-CSCF, then the HSS would have included in this UAA message also the SIP URI of the S-CSCF in question, so that the I-CSCF would contact this S-CSCF directly.
Afterwards, it sends a Diameter Cx-Query response or Diameter UAA – Diameter User-Authorization-Answer command back to the I-CSCF. This message should contain, in a favorable case, the capabilities of the S-CSCF server that this I would have to look for in order to allocate to that UE.
As per RFC 4740 – section 8.2, this command message should look like this:
       <UAA> ::= < Diameter Header: 283, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ SIP-Server-URI ]

                 [ SIP-Server-Capabilities ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]
22. Register
After looking at the S-CSCF capabilities it received from the HSS, the I-CSCF looks through its S-CSCFs list and selects one that matches the capabilities indicated by the HSS. Then it forwards the Register message to this S-CSCF. These capabilities are some mandatory and some optional. The I-CSCF must select an S that matches the mandatory capabilities and may match some, all or none of the optional ones. The exact implementation of these capabilities is at the operator’s discretion, this entire communication being on his internal network.
The REGISTER message between the I-CSCF and the S-CSCF looks like this:
REGISTER sip:home.net SIP/2.0
Via: SIP/2.0/UDP icscf1.home.net;branch=z9hG4bKea1dof,
SIP/2.0/UDP pcscf1.visited.net;branch=z9hG4bKoh2qrz,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 68
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
From: <sip:alice_public@home.net>;tag=s8732n
To: <sip:alice_public@home.net>
Contact: <sip:[1080::8:800:200C:417A];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”alice_private@home.net”,realm=”home.net”, nonce=””, uri=”sip:home.net”, response=””, integrity-protected=”no”
Require: path
Supported: path
Path: <sip:term@pcscf1.visited.net;lr>
P-Visited-Network-ID: “Cristina Visited Network”
P-Charging-Vector: icid-value=”1234bc9876e”
Cseq: 1 REGISTER
Content-Length: 0
The only thing new here is the fact that the I-CSCF adds its URI on top of the Via header content.
23. Diameter MAR
The next message in the flow is the one sent by the S-CSCF chosen by the I-CSCF (the one that received the REGISTER message above) to the HSS.
There are 2 reasons the S-CSCF communicates with the HSS:
a. to retrieve the AV – Authentication Vector with challenges for this UE, in order to be able to authenticated it
b. to save its Request-URI into the HSS, so that for any further requests that may be received by the network from this subscriber, the HSS knows it has already assigned a S-CSCF for this user
The S-CSCF sends to the HSS a message called Diameter MAR – Multimedia-Auth-Request. According to RFC 4740 – section 8.7, this message should look like this:
       <MAR> ::= < Diameter Header: 286, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 { SIP-Method }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
                 [ SIP-Number-Auth-Items ]
                 [ SIP-Auth-Data-Item ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

24. Diameter MAA

Diameter MAA – Multimedia-Auth-Answer, as per RFC  4740 – section 8.8, is the message sent from the HSS to the S-CSCF containing the AV – authentication vectors – one or more. Based on this vectors, the S-CSCF is able to authenticate the user by sending a SIP 401 Unauthorized message to this UA.

The MAA message should look like this:

       <MAA> ::= < Diameter Header: 286, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
                 [ SIP-AOR ]
                 [ SIP-Number-Auth-Items ]
               * [ SIP-Auth-Data-Item ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

25. 401 Unauthorized

This message contains the important information for authenticating the UA: the WWW-Authenticate header.

This message would look the following, between the S-CSCF and I-CSCF:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP icscf1.home.net;branch=z9hG4bKea1dof,
SIP/2.0/UDP pcscf1.visited.net;branch=z9hG4bKoh2qrz,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
From: <sip:alice_public@home.net>;tag=s8732n
To: <sip:alice_public@home.net>;tag=n3278s
Call-ID: 23fi57lju

WWW-Authenticate: Digest realm=”home.net”,nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093″,algorithm=AKAv1-MD5

Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=909767; spi-s=421909;port-c:4444; port-s=5058
Cseq: 1 REGISTER
Content-Length: 0

26. 401 Unauthorized

27. 401 Unauthorized

Messages 26. and 27. are pretty much the same as the one above, with the only difference of the Via header, which will only contain the Request URI of the User Agent.

—– what the UE does with this message and what happens next: in the next episode 😛 —–

Advertisements
Comments

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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