Posts Tagged ‘Register’

This is a summary of what I hope to be able to describe in the next several posts: the establishment of a basic SIP-IMS call flow, in a somewhat interesting scenario: when both Alice and Bob are in roaming.

Each of the participants talks to his/her own P, S and I servers. Here the presumption is that Alice is the one making the phone call.

sip-ims-call

“c1” because…mwell, because “a” was the register and 4G/IMS architecture, “b” was the OpenIMSCore and “c” should be an actual call flow.

Unfortunately, I cannot show you the actual 4G encapsulation, because I don’t have any tool to emulate that, but, as we’ve understood from the registration flow, each IMS message coming from or going to the IMS mobile device will be encapsulated in GTPv1-u header between the eNodeB, SGW, PGW and then forwarded, without the GTPv1-u encapsulation, to the P-CSCF. Juuust as for the Register flow…

4g-ims

Oook, now let’s take a look at the IMS-SIP call flow. Basically, what I’m going to show here is a Basic Call with Voice.

Now, the most basic SIP (Session Initiation Protocol) call flow has the following structure:

sip-basic

Basically, Alice sends an INVITE message to Bob (via a sip proxy server or directly), inviting Bob to a voip message exchange, and also sending in the SDP (Session Description Protocol) header (presented as a SIP message body), the RTP (Real-Time Protocol) codecs that Alice’s phone is supporting. 1xx is provisional messaging. 100 Trying and 180 Ringing is a good sign, they mean I am actually contacting Bob, I am just waiting for him to pick-up the phone. When he does that, his device signals a 200 OK (sending in this message also the RTP codecs known by Bob’s device), and Alice’s device Acknowledges. Now the RTP session can begin, with one of the matching codecs. Once the two guys finish talking, Alice’s phone (usually) is the one signaling the end of the conversation, by sending a BYE message to Bob, and this one acknowledges. Alice can also send her supported RTP codecs barely in her ACK message, procedure called late negotiation.

Now, this may rightfully seem simple enough, but wait! We haven’t yet got to the IMS part 🙂

The same “basic” SIP call flow in the IMS context would look like this (of course, excluding the 4G encapsulation which we’ve agreed we understand):

sip-basic-IMS

In the next chapter I’ll detail these messages.

For the moment, let’s just observe the presence of a weird new message called PRACK. The PRACK is defined in RFC3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP). The RFC 3262 states:

   The PRACK request plays the same role as ACK, but for
   provisional responses.  There is an important difference, however.
   PRACK is a normal SIP message, like BYE.  As such, its own
   reliability is ensured hop-by-hop through each stateful proxy.  Also
   like BYE, but unlike ACK, PRACK has its own response.  If this were
   not the case, the PRACK message could not traverse proxy servers
   compliant to RFC 2543 [4]."

I believe the IETF guys are pretty explanatory 🙂

See you in the next chapter.

WONDERFUL tool. Kindda weird to configure at first, but, once you have clear in mind what you want to do, it seems really intuitive.

I have it on a debian 5.0.5. Installed in /opt/OpenIMSCore

It has 4 main components:

P-CSCF, I-CSCF, S-CSCF and HSS – and, as far as I have understood from my knowledgeable colleagues who have done this, these components can be installed separately on different machine. I have installed them bulky on a single machine.

Ah, and it needs a DB server (HSS being a DB afterall) – I have used MySQL and a DNS server – I have used bind9, on the same machine. The Fraunhofers are nice guys and give you the DNS file zone and a lot of scripts to make your work of configuring the proxies, as well as adding and managing users, much easier.

So, briefly, where are the configuration files, what I have changed in each of them to make them work, which scripts I have used and what users I have (the IMS dumps from the previous post shows a user called Cristina who registers to this IMS core and does a SIP call – we’ll see that also).

imacandi:/opt/OpenIMSCore# ls
add-imscore-user_newdb.sh  dbdump.sh                 fhoss.sh        icscf.thig.sh  pcscf.cfg       scscf.cfg  TGPPGq.xml      trcf.sh
add-user-cristina.sql      delete-user-cristina.sql  icscf.cfg       icscf.xml      pcscf.sh        scscf.sh   TGPPRx.xml
add-user-sin.sql           delete-user-sin.sql       icscf.sh        mgcf.cfg       pcscf.xml       scscf.xml  tls_prepare.sh
configurator.sh            FHoSS                     icscf.thig.cfg  mgcf.sh        remove_sems.sh  ser_ims    trcf.cfg
I guess it would be nice and mostly USEFUL, to read the OpenIMSCore install howto (don’t worry, is not long) BEFORE continuing – at least if you want to apply the following information as a “howto”. If you are reading just as a lecture, you may just continue.
And we are firstly interested in the configuration files of the proxies and the database. They are already created at installation time, and I have copied them (as per the installation howto), directly under /opt/OpenIMSCore.
They are:
/opt/OpenIMSCore/pcscf.cfg
/opt/OpenIMSCore/icscf.cfg
/opt/OpenIMSCore/scscf.cfg
/opt/OpenIMSCore/FHoSS/deploy/DiameterPeerHSS.xml
The pcscf.cfg is the config for the P-CSCF – big surprise, heh?
The only change I made here was the IP address the P-CSCF uses for opening the socket:
listen=22.22.22.22
port=4060
alias=”pcscf.open-ims.test”:4060
This file has the directives for the modules to be loaded by the pcscf daemon and also the main routing logic.  This routing logic part is a set of decisional actions based on the values of different headers from the SIP messages, like the Method type or the length of the message, or the value of max_forwards header or whether or not this is the initiator of a dialog and so on…
The pcscf.xml is another configuration file, containing declarations of the DiameterPeer, FQDN, Default Route, Realms and Authentication Identifiers. The only changes I’ve done in this file where related to the port where the P-CSCF listens for the Diameter communication:
<Acceptor port=”3867″ bind=”22.22.22.22″/>
This is specially useful if you have the HSS on a different machine (which is the real use-case).
And there is also the pcscf.sh, which is a basic start/stop script.
Now, the example with the pcscf config above is basically the same for the icscf and scscf.
The /opt/OpenIMSCore/FHoSS/deploy/DiameterPeerHSS.xml file contains some similar configuration for the HSS, where the only change was the Acceptor IP and port.
Oh, and one more thing, in order to be able to actually start the HSS you need to have the JAVA_HOME variable set.
Mine is JAVA_HOME=/usr/lib/jvm/java-6-sun.
Then I’ve started the HSS like this:
# cd /opt/OpenIMSCore/FHoSS/deploy
# ./startup.sh
By default, everything starts in debug mode, so I have 4 screens where I start the P, S, I and HSS, and then another one to play with.
It looks like this:
openimscore
— At this is the no-TLS way to configure it: not much to configure, actually.

Continuing from 4G – GTPv2 dumps:

First of all, bare in mind that this is NOT the actual end-to-end testing procedure, so I can only show so far a basic IMS call coming from plain IP, therefore with no indication to the Access Network:

Register

The P-CSCF listens on port 4060 UDP (as we will see in the next episode, the configuration of the IMS Core), and the phone is on 5060:

Session Initiation Protocol
Request-Line: REGISTER sip:open-ims.test SIP/2.0
Method: REGISTER
Request-URI: sip:open-ims.test
Request-URI Host Part: open-ims.test
[Resent Packet: False]
Message Header
Call-ID: e052b1ac4b0e861a09f50739567f57ff@40.0.0.1
CSeq: 19 REGISTER
Sequence Number: 19
Method: REGISTERrnFrom
From: <sip:cristina@open-ims.test>;tag=1020
SIP from address: sip:cristina@open-ims.test
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1020
To: <sip:cristina@open-ims.test>
SIP to address: sip:cristina@open-ims.test
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
Via: SIP/2.0/UDP 40.0.0.1:5060;branch=z9hG4bK163b18a8645e3542f3430be441fc7021
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
Branch: z9hG4bK163b18a8645e3542f3430be441fc7021
Max-Forwards: 20
Expires: 3600
Contact: <sip:cristina@40.0.0.1:5060>
Contact-URI: sip:cristina@40.0.0.1:5060
Contactt-URI User Part: cristina
Contact-URI Host Part: 40.0.0.1
Contact-URI Host Port: 5060
User-Agent: Fokus MONSTER Version: 0.9.9-SNAPSHOT
Content-Length: 0
401 Unauthorized
Session Initiation Protocol
Status-Line: SIP/2.0 401 Unauthorized – Challenging the UE
Status-Code: 401
Message Header
Call-ID: e052b1ac4b0e861a09f50739567f57ff@40.0.0.1
CSeq: 19 REGISTER
Sequence Number: 19
Method: REGISTERrnFrom
From: <sip:cristina@open-ims.test>;tag=1020
SIP from address: sip:cristina@open-ims.test
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1020
To: <sip:cristina@open-ims.test>;tag=d7837ce6bbd631122d10546eb75bb4cf-cb8c
SIP to address: sip:cristina@open-ims.test
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
SIP tag: d7837ce6bbd631122d10546eb75bb4cf-cb8c
Via: SIP/2.0/UDP 40.0.0.1:5060;rport=5060;branch=z9hG4bK163b18a8645e3542f3430be441fc7021
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
RPort: 5060
Branch: z9hG4bK163b18a8645e3542f3430be441fc7021
Path: <sip:term@pcscf.open-ims.test:4060;lr>
Service-Route: <sip:orig@scscf.open-ims.test:6060;lr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO
Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))
Content-Length: 0
Warning: 392 127.0.0.1:6060 “Noisy feedback tells:  pid=19702 req_src_ip=127.0.0.1 req_src_port=5060 in_uri=sip:scscf.open-ims.test:6060 out_uri=sip:scscf.open-ims.test:6060 via_cnt==3”
WWW-Authenticate: Digest realm=”open-ims.test”, nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”, algorithm=AKAv1-MD5, qop=”auth,auth-int”
Authentication Scheme: Digest
realm=”open-ims.test”
nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”
algorithm=AKAv1-MD5
qop=”auth
Register
– the one with credentials 😛
Session Initiation Protocol
Request-Line: REGISTER sip:open-ims.test SIP/2.0
Method: REGISTER
Request-URI: sip:open-ims.test
Request-URI Host Part: open-ims.test
[Resent Packet: False]
Message Header
Call-ID: 1e867b19168f09121f91914b048d97d1@40.0.0.1
CSeq: 20 REGISTER
Sequence Number: 20
Method: REGISTERrnFrom
From: <sip:cristina@open-ims.test>;tag=1021
SIP from address: sip:cristina@open-ims.test
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1021
To: <sip:cristina@open-ims.test>
SIP to address: sip:cristina@open-ims.test
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
Via: SIP/2.0/UDP 40.0.0.1:5060;branch=z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
Branch: z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
Max-Forwards: 20
[truncated] Authorization: Digest username=”cristina@open-ims.test”,uri=”sip:open-ims.test”,realm=”open-ims.test”,nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=””,response=”edfe66ab211e300fea4da5bd308605c3″,algoritm=AKAv1-MD5,qop=auth-int
Authentication Scheme: Digest
username=”cristina@open-ims.test”
uri=”sip:open-ims.test”
realm=”open-ims.test”
nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=””
response=”edfe66ab211e300fea4da5bd308605c3″
algoritm=AKAv1-MD5
qop=auth-int
nc=00000001
cnonce=”48525798509797101″
Expires: 3600
Contact: <sip:cristina@40.0.0.1:5060>
Contact-URI: sip:cristina@40.0.0.1:5060
Contactt-URI User Part: cristina
Contact-URI Host Part: 40.0.0.1
Contact-URI Host Port: 5060
User-Agent: Fokus MONSTER Version: 0.9.9-SNAPSHOT
Content-Length: 0
200 OK
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK – SAR succesful and registrar saved
Status-Code: 200
[Resent Packet: False]
[Request Frame: 81]
[Response Time (ms): 106]
Message Header
Call-ID: 1e867b19168f09121f91914b048d97d1@40.0.0.1
CSeq: 20 REGISTER
Sequence Number: 20
Method: REGISTERrnFrom
From: <sip:cristina@open-ims.test>;tag=1021
SIP from address: sip:cristina@open-ims.test
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1021
To: <sip:cristina@open-ims.test>;tag=d7837ce6bbd631122d10546eb75bb4cf-3d08
SIP to address: sip:cristina@open-ims.test
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
SIP tag: d7837ce6bbd631122d10546eb75bb4cf-3d08
Via: SIP/2.0/UDP 40.0.0.1:5060;rport=5060;branch=z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
RPort: 5060
Branch: z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
P-Associated-URI: <sip:cristina@open-ims.test>
Contact: <sip:cristina@40.0.0.1:5060>;expires=3600
Contact-URI: sip:cristina@40.0.0.1:5060
Contactt-URI User Part: cristina
Contact-URI Host Part: 40.0.0.1
Contact-URI Host Port: 5060
Contact parameter: expires=3600
Path: <sip:term@pcscf.open-ims.test:4060;lr>
Service-Route: <sip:orig@scscf.open-ims.test:6060;lr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO
Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))
Content-Length: 0
Warning: 392 127.0.0.1:6060 “Noisy feedback tells:  pid=19703 req_src_ip=127.0.0.1 req_src_port=5060 in_uri=sip:scscf.open-ims.test:6060 out_uri=sip:scscf.open-ims.test:6060 via_cnt==3”

Knowing it is not very nice to talk a lot about a certain thing, but to offer no tangible results, I’ve tried to create some minimal dump information for the things discussed lately on my posts.

They should be, though not end-to-end results, at least some hope-by-hope information.

So, let’s see first how an Initial Attach to the 4G network would look like, then how the UE asks for a dedicated bearer to put traffic on (specifically to put VoIP traffic on), and then take a closer look at a IMS call flow.

For the 4G dumps I must give credit to the wonderful company I work in, which helps me develop on the 4G core network side. While the IMS flows are generated using OpenIMSCore and Monster, the 2 solutions from the cool guys from Fraunhofer.

(more…)

28. Register

29. Register

This is the REGISTER message that the UA composes AFTER receiving the 401 Unauthorized. The UA retrieves the authentication information from the UE, which, in the case of 3GPP phones, is stored in the UICC – Universal Integrated Circuit Card. The new Register message looks like this:

REGISTER sip:home.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 70
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:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”alice_private@home.net”,realm=”home.net”,
nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093″,algorithm=AKAv1-MD5, uri=”sip:home.net”, response=”6629fae49393a05397450978507c4ef1″
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=909767; spi-s=421909;
port-c:4444; port-s=5058
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 2 REGISTER
Supported: path
Content-Length: 0
The only difference between them is the Via header, due to the SIP message passing through the
servers.
Now, when this Register message reaches the P-CSCF, this device will do a new DNS query for the I-CSCF IP address. This is usual, as there are usually multiple I-CSCF servers in a network and there is no rule that once an I-CSCF responds to the first UA query this same I-CSCF must also respond to the subsequent queries. This rule dose NOT apply though for the S-CSCF server -which, as we’ve seen in the previous posts, is allocated per UA. So, the P-CSCF gets a (new) IP address of an I-CSCF and forwards there this message.

30. Diameter UAR

At this point, the I-CSCF gets the Register message above. As the I-CSCF has no state of the UA status on the home network, and it also does not know if the HSS already assigned an S-CSCF to the UA or not, the I-CSCF has to contact the HSS again, via the Cx interface, get the address of the S-CSCF allocated for this UA and forward this Register to the right S-CSCF.

31. Diameter UAA

Diameter UAR and Diameter UAA have the same format as before:

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

32. Register

This is the step where the Register message is transmitted from the I-CSCF to the S-CSCF. The S-CSCF is the one allocated by the HSS in the previous Register flow (answered with 401 Unauthorized) and now the HSS sends the URI of this allocated S-CSCF to the I-CSCF in the Diameter UAA message from Step 31 above.

33. Diameter SAR

When the S-CSCF receives the Register message with credentials from the UA, it authenticates this UA versus the AV – Authentication Vector is received from the HSS in the previous Step 24. Diameter MAA message. After this, the UA is considered authenticated, so now the S-CSCF should have also its profile (stored in the HSS), in order to know which services are available for it. In order to get this profile and also so let the HSS know that the UA is now registered, the S-CSCF sends the Cx-Put or Diameter SAR – Server-Assignment-Request message to the HSS, via the Cx interface.

According to RFC 4740 – section 8.3, the Diameter SAR message should look like this:

 

       <SAR> ::= < Diameter Header: 284, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-Server-Assignment-Type }
                 { SIP-User-Data-Already-Available }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
               * [ SIP-Supported-User-Data-Type ]
               * [ SIP-AOR ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

34. Diameter SAA

This is the reply sent by the HSS to the S-CSCF, Cx-Put response or Diameter SAA – Server-Assignment-Answer, which contains the user profile. This user profile contains all the Public User Identities of this UA, identities that are associated to the Private User Identity, and also all the public identities that are to be automatically (or implicitly) registered in the S-CSCF.

The user profile also has a set of initial filter criteria – a set of rules which determine when a SIP request is forwarded to an Application Server for a certain service request. The Contact URI of the UA that the S-CSCF store in the HSS it the actual value of the Contact header from the Register message. The S-CSCF also stores the values from the Path header in order to know where to route the SIP initial requests for that UA to.

As per RFC 4740 – section 8.4, this message looks like this:

 

       <SAA> ::= < Diameter Header: 284, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
               * [ SIP-User-Data ]
                 [ SIP-Accounting-Information ]
               * [ SIP-Supported-User-Data-Type ]
                 [ User-Name ]
                 [ Auth-Grace-Period ]
                 [ Authorization-Lifetime ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

35. 200 OK

Then the S-CSCF responds to the Register message by sending a 200 OK message. This message contains also a P-Associated-URI list – list of the Associated URIs where this UA can be located, according to the S-CSCF – this list is not necessarily the same as the list of implicitly registered public user identities.

The S-CSCF also inserts a Service-Route header, which contains its own URI with a string in the user part, in order to differentiate mobile originated requests from mobile terminating requests.

36. 200 OK

37. 200 OK

These messages are basically the same, except the Via header. When it reaches the UE, the 200 OK message looks like this:

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab

Path: <sip:term@pcscf1.visited.net;lr>

Service-Route: <sip:orig@scscf1.home.net;lr>

From: <sip:alice_public@home.net>;tag=s8732n

To: <sip:alice_public@home.net>;tag=409sp3

Call-ID: 23fi57lju

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:5059;comp=sigcomp>;expires=600000

Cseq: 2 REGISTER

Date: Wed, 21 January 2004 18:19:20 GMT

P-Associated-URI: <sip:alice-family@home.net>,<sip:alice-business@home.net>,

<sip:+1-212-555-1234@home.net;user=phone>

Content-Length: 0

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 😛 —–

18. DNS query

The specifics of the SIP information retrieval via DNS queries are described in RFC 3263 – Session Initiation Protocol (SIP): Locating SIP Servers. This RFC details the SIP specificities on top of RFC 2782 – A DNS RR for specifying the location of services (DNS SRV).

In our case, the P-CSCF of the visited domains looks at the Request-URI the UE sent in its Register message. It observes this domain is different than its own, so it concludes the UE is in roaming, so it has to locate the home I-CSCF, in order to see if it can serve this subscriber or not.

So, what steps does the visited P take in order to get to the right home I?

The P performs a NAPTR query for the domain specified in the Request-URI;

This NAPTR thinggie comes from Name Authority Pointer and it is actually a type of DNS RR – Resource Record. The reason behind the invention of this horrible RR is the quest to map everything around the interwebs – we’re mapping you over!!! Resistance is futile !!! HA HA HAAA 😛

Now, seriously, they are trying to map resources like services (like printers, LDAP servers or..why not…I-CSCF servers!!!) to a plain domain name. This NAPTR has a specific structure:

– service name

– set of flags

– regexp rule (yes, regular expressions, we all hate them 😛 , or at least I surely do so, at least after the Perl learning tentative I had a while back)

– an order value

– a preference

– replacement

and, even more, they can also come chained in multiple records carefully cascaded to make our poor lives even more miserable.

These NAPTR things are standardized by RFC 2915 and RFC 3403. Good luck with that!

Moving on, let’s take a look at how a P-CSCF NAPTR Query may look like:

OPCODE=SQUERY

QNAME=registrar1.home.net, QCLASS=IN, QTYPE=NAPRT

The NAPTR Response would be like this:

OPCODE=SQUERY, RESPONSE, AA

QNAME=registrar1.home.net, QCLASS=IN, QTYPE=NAPTR

registrar1.home.net       0   IN   NAPTR   50 50 “s” “SIP+D2U” “” _sip._udp.registrar1.home.net

0   IN   NAPTR 90 50 “s” “SIP+D2T” “” _sip._tcp.registrar1.home.net

0   IN   NAPTR 100 50 “s” “SIPS+D2T” “” _sips._tcp.registrar1.home.net

UDP is preferred, as the UDP record appears first – order criteria. The “s” means this is a SRV record. What this P needs to do further on is to perform a SRV Query at the address provided in the NAPTR record first ( _sip._udp.registrar1.home.net) in order to get the services supported by this guy (the I-CSCF).

The SRV Query would look something like this:

OPCODE=SQUERY

QNAME=_sip._udp.registrar1.home.net, QCLASS=IN, QTYPE=SRV

And the SRV Response:

OPCODE=SQUERY, RESPONSE, AA

QNAME=_sip._udp.registrar1.home.net, QCLASS=IN, QTYPE=SRV

_sip._udp.registrar1.home.net   0   IN   SRV   1   10   5060   icscf1_p.home.net

0   IN   SRV   1   0   5060   icscf7_p.home.net

icscf1_p.home.net   0   IN   AAA   5555::aba:abb:abc:abd

icscf7_p.home.net   0   IN   AAA   555::dba:dbb:dbc:dbd

Here there are listed all the I-CSCF proxies in the home.net domain, with their Priority and Weight. The best one will be chosen, according to the rules defined in RFC 2782. As the answer also contains the IP address of the I-CSCF, the visited P-CSCF will forward the REGISTER message to this I-CSCF (here icscf1), on port 5060.

As I was saying in part 3: let’s get down to business 🙂
The 4G portion of the 4G – IMS registration has been described in Part 1;
The IP-CAN Session Establishment has been described in Part 2;
The generic IMS specifications (at least part of them) have been described in Part 3;

Now, let’s analyze the messages from the IMS – SIP signaling. As I was saying, these messages are tunneled between the eNodeB and PGW via GTPv1-U protocol. Then they reach the P-CSCF and are forwarded in the IMS core. This P-CSCF entity, often called simply P, can be located – and usually it is, specially in the roaming scenarios, … located in the visited network.

Before continuing to the description of each of the messages in the IMS registration, let’s take another look at the 4G – IMS architecture, as well as to the registration flow that we describe:

4g-ims

4G-IMS Architecture

4G-IMS RegistrationFlow

4G-IMS

16. P-CSCF Discovery

– described in TS 23.228: section 5.1.1 Procedures related to Proxy-CSCF discovery and

section E.1.1.1 GPRS/EPS procedure for P-CSCF discovery

Because the procedure is pretty straight-forward, I will just copy-paste it from the spec above:

The Proxy CSCF discovery shall be performed using one of the following mechanisms:
– As part of the establishment of connectivity towards the IP-Connectivity Access Network, if the IP-Connectivity Access Network provides such means.
Alternatively, the P CSCF discovery may be performed after the IP connectivity has been established. To enable P CSCF discovery after the establishment of IP connectivity, the IP-Connectivity Access Network shall provide the following P CSCF discovery option to the UE:
Use of DHCP to provide the UE with the domain name and/or IP address of a Proxy CSCF and the address of a Domain Name Server (DNS) that is capable of resolving the Proxy CSCF name, as described below in clause 5.1.1.1.
The UE may be configured (e.g. during initial provisioning or via a 3GPP IMS Management Object (MO), TS 24.167 [64] or in the ISIM, TS 31.103 [69]) to know the fully qualified domain name (FQDN) of the P CSCF or its IP address. If the domain name is known, DNS resolution is used to obtain the IP address.
In the case where UE is aware of more than one P CSCF address, the selection shall be based on home operator configured policy to select the P CSCF.
NOTE:Subject to home operator policy, the UE selects the Home P CSCF to be used by either using a pre-configured Home P CSCF FQDN or according to TS 24.167 [64]. This can be done without the UE first performing the local P CSCF discovery (e.g. DHCP).

Section 5.1.1.1 describes the DHCP/DNS procedure for P-CSCF discovery:

The DHCP relay agent within the IP-Connectivity Access Network relays DHCP messages between UE and the DHCP server.

p-cscf-dhcp-dns

1.Establish an IP-Connectivity Access Network bearer if not already available by using the procedures available in the IP-Connectivity Access Network.

2.The UE requests a DHCP server and additionally requests the domain name and/or IP address of the P‑CSCF and IP addresses of DNS servers. It may require a multiple DHCP Query/Response message exchange to retrieve the requested information.

3.The UE performs a DNS query to retrieve a list of P‑CSCF(s) IP addresses from which one is selected. If the response does not contain the IP addresses, an additional DNS query is needed to resolve a Fully Qualified Domain Name (FQDN) to an IP address.

After reception of domain name and IP address of a P‑CSCF the UE may initiate communication towards the IM subsystem.

Section E.1.1.1 describes the GPRS/EPS procedure for P-CSCF discovery

I will just show the 4G part, procedure valid for both E-UTRAN Initial Attach procedure, as well as for subsequent PDN Connectivity Requests:

p-cscf-eps-bearer

1.   During Initial Attach/PDN Connection Request, the UE indicates that it requests a P‑CSCF IP address(es).

2.   The MME sends a Create Default Bearer Request to the S‑GW.

3.   The S‑GW forwards the request to the P‑GW and the P‑GW gets the IP address(es) of the P‑CSCF(s). The mechanism to do this is a matter of internal configuration and is an implementation choice.

4.   If requested by the UE, the P‑GW includes the IP address(es) of the P‑CSCF(s) in the Create Default Bearer Response.

5.   The S‑GW forwards the response to the MME

6.   Completion of procedures, as described in TS 23.401 [70].

After reception of the IP address of a P‑CSCF the UE may initiate communication towards the IM CN Subsystem.

17. Register message sent from the IMS terminal to the P-CSCF

Once the IMS terminal obtains its IP address, it must register to the IMS network. This happens in order for the UE to authenticate and obtain authorization to use the IMS network resources. The IMS registration is accomplished by the SIP REGISTER message – this being also the only SIP message that is authenticated by the network (subsequent SIP messages, like INVITE, 200 OK…and so on, are not being authenticated).

First of all, we should know that the IMS-SIP is a SIP (RFC 3261) on steroids (as my SIP colleague use to joke 😛 ), because it has a lot of 3GPP enhancements to meet the 3GPP requirements for this type of communication – I won’t get into details right now. One requirement is that, in IMS, unlike in regular SIP, a phone cannot make any call without first being registered to the IMS network.

Second of all, let’s establish the meaning of this “register” procedure. What the REGISTER procedure does is bind the public URI of that IMS user to a certain IP address and/or host name. The IP address/host name are the ones given by the IP-CAN Session during attach or later on. It is the means of locating that phone in the network. The point is to let the IMS network know at which actual address (IP/host name) it can find a user it has configured as subscriber.

Short note: this public URI thinggie is the identity of the subscriber, something like an e-mail address, only less pretty :P. It can also contain a bunch of weird parameters that I won’t get into details with right now:

examples of SIP URIs:

sip:Alice.Smith@domain.com

sip:Bob.Brown@example.com

sip:carol@ws1234.domain2.com;transport=tcp

SIP URIs with SDP information (SDP – Session Description Protocol) :

v=0

o=Bob 234562566 236376607 IN IP4 192.0.0.2

s=Let’s talk about martial arts

c=IN IP4 22.22.22.22

t=0 0

m=audio 30000 RTP/AVP 0

a=sendrecv

m=video 30002 RTP/AVP 31

a=sendrecv

Before actually taking a look at this fancy SIP REGISTER message, let’s present the IMS requirements for SIP Registration:

[Bear in mind that many of the information below are inspired/taken from the following book:

http://www.amazon.com/3G-IP-Multimedia-Subsystem-IMS/dp/0470871563

The 3G IP Multimedia System: Merging the Internet and the Cellular Worlds

by Gonzalo Camarillo and Miguel-Angel Garcia-Martin ]

The IMS registration procedure satisfies the following requirements in two round trips:

(a) the user binds a Public User Identity to a contact address – this is the main purpose ofa SIP REGISTER request;

(b) the home network authenticates the user;

(c) the user authenticates the home network;

(d) the home network authorizes the SIP registration and the usage of IMS resources;

(e) in case the P-CSCF is located in a visited network, the home network verifies that there is an existing roaming agreement between the home and the visited network and authorizes the usage of the P-CSCF;

(f) the home network informs the user about other possible identities that the homenetwork operator has allocated exclusively to that user;

(g) the IMS terminal and the P-CSCF negotiates the security mechanism that will be in place for subsequent signaling;

(h) the P-CSCF and the IMS terminal establish a set of security associations that protect the integrity of SIP messages sent between the P-CSCF and the terminal;

(i) both the IMS terminal and the P-CSCF upload to each other the algorithms used for compression of SIP messages.

Before creating the SIP Register message, the UE terminal retrieves the Private User Identity from its ISIM card, along with its Public User Identity and its home network domain URI.
OK, so let’s take a look at the actual SIP REGISTER message the IMS terminal sends to its P-CSCF, via the 4G Access Network:
REGISTER sip:registrar1.home.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 70
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:[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=””
Security-Client: ipsec-3gpp; alg=hmac-sha-1-96;spi-c=3929102; spi-s=0293020; port-c:3333; port-s=5059
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 1 REGISTER
Supported: path
Content-Length: 0
1. The first line identifies the method, which is REGISTER, then it is followed by the Request-URI. This Request-URI identifies the destination domain of the Register request.
– this Request-URI has the role of registration URI which identifies the home network or a subdomain of the network
2. The Via header is the IP address ( here: 5555::aaa:bbb:ccc:ddd) given to the UE during the initial attach or bearer activation, statically or dynamically (IP-CAN) assigned.
3. The P-Access-Network-Info represents the access type and information related to the access network, in our case, a 3GPP 4G network – LTE wireless, FDD, with the specified cell id.
4. The To: and From: fields are usually taken from the USIM. These fields have the same value in the Register message, representing the Public User Identity, also called Address-of-Record. This is the identity the other parties know and use to contact this UE.
5. The Contact: header represents the temporary point of presence for this UE. Its value is the most recent IP address the UE has and this address is stored in the S-CSCF. This is the third important parameter about the UE, the Contact Address (the other two being the registration URI and Address-of-Record).
6. The Authorization field caries out authentication information about the terminal. This information is the forth parameter used for registration, having the role of the Private User Identity. This value is the equivalent of the IMSI field in the GSM system and it should not be displayed to the user. It is used by the AKA fields to authenticated the user. This parameter is composed by the private ID and the domain name of the home network where the UE registers.
The nonce and response parameters are empty, because this case considers the terminal has just been turned on for the first time, otherwise there should have been some cached information to send here.
7. The Security-Client field lists the algorithms supported by the UE. In this case, the terminal has IPsec capabilities.
8. The client requires the parties to agree on its security parameters and also indicates it supports the Path header.
Before moving on to the DNS query functions of the P-CSCF, we should know that usually the P-CSCF is not located in the same network as the home network of the UE. This is why it is very possible it does not have an entry point into the user’s home network. Still, in order to be able to serve this UE, the P uses information from the user in order to locate the I-CSCF from the home network. This procedure is a DNS query specified in RFC 3263 and its purpose is to give this P a SIP URI of the home network I. After the P locates this I, it will forward the REGISTER message to the I, inserting along a P-Visited-Network-ID header that identifies the location (domain name of the network) of the P.
This P-Visited-Network-ID is necessary so that the home network verifies it actually has a roaming agreement with the visited network. Also, the P-CSCF inserts its own SIP URI into the Path header, so that the I-CSCF knows where to forward the reply. It is important that the Path header is populated, so that every request from the home network is forwarded via this P-CSCF visited network proxy, otherwise the requests will never reach our roaming subscriber.
— the DNS query procedures in the next episode —

This is a continuation of the 4G – IMS topic I’ve started a while back.

Still, before continuing the IMS registration started in windancersth.wordpress.com/2010/08/26/4g-to-ims-call-flow-register-to-ims.html

I would like to show a preview of the Specs describing this fancy IMS thinggie.

[This information is not structured by me, but it was on tech-invite, before they decided to put a price on all that information.]

The General aspects:

3GPP TS 22.228 Service Requirements for the IP Multimedia Core Network (IM CN) Subsystem – Stage 1
3GPP TS 23.228 IP Multimedia Subsystem (IMS) – Stage 2
Registration:
RFC 3327SIP “Path” Extension Header Field for Registering Non-Adjacent Contacts
RFC 3608SIP Extension Header Field for Service Route Discovery during Registration
Diameter:
3GPP TS 29.109GAA – Zh and Zn Interfaces based on the Diameter protocol – Stage 3
3GPP TS 29.229Cx and Dx interfaces based on the Diameter protocol – Protocol Details
3GPP TS 29.230Diameter Applications – 3GPP Specific Codes and Identifiers
3GPP TS 29.329Sh Interface based on the Diameter protocol – Protocol Details
3GPP TS 32.299 Charging Management – Diameter Charging Applications
RFC 3588Diameter Base Protocol
RFC 3589Diameter Command Codes for 3GPP Release 5
RFC 4740 Diameter Session Initiation Protocol (SIP) Application
Identification:
3GPP TS 23.228 IP Multimedia Subsystem (IMS) – Stage 2
3GPP TS 29.229 Cx and Dx interfaces based on the Diameter protocol – Protocol Details
RFC 4282 The Network Access Identifier
Policy:
3GPP TS 23.203 Policy and Charging Control Architecture
3GPP TS 29.207Policy Control over Go Interface
3GPP TS 29.208End-to-end Quality of Service (QoS) Signalling Flows
3GPP TS 29.209Policy control over Gq Interface
Charging:
3GPP TS 22.115Service Aspects – Charging and Billing
3GPP TS 32.240Charging Architecture and Principles
3GPP TS 32.260 IP Multimedia Subsystem (IMS) Charging
3GPP TS 23.125 Overall high level functionality and architecture impacts of flow based charging – Stage 2
3GPP TS 23.203 Policy and Charging Control Architecture
3GPP TS 29.210Charging Rule Provisioning over Gx Interface
3GPP TS 29.211Rx Interface and Rx/Gx Signalling Flows
3GPP TS 23.203Policy and Charging Control Architecture
3GPP TS 32.295Charging Data Record (CDR) Transfer
3GPP TS 32.296Online Charging System (OCS): Applications and Interfaces
3GPP TS 32.297Charging Data Record (CDR) File Format and Transfer
3GPP TS 32.298Charging Data Record (CDR) Parameter Description
3GPP TS 32.299Diameter Charging Applications
Security:
3GPP 33-series3GPP Specifications related to Security
QoS:
3GPP TS 23.107Quality of Service (QoS) Concept and Architecture
3GPP TS 23.207End-to-end Quality of Service (QoS) Concept and Architecture
3GPP TS 29.208End-to-end Quality of Service (QoS) Signalling Flows
OSA:
3GPP TS 22.127 Service Requirement for the Open Service Access (OSA) – Stage 1
3GPP TS 23.198Open Service Access (OSA) – Stage 2
3GPP TS 29.19829.198 series: Open Service Access (OSA) API
3GPP TS 29.19929.199 series: OSA Parlay X Web Services
CAMEL:
3GPP TS 22.078 CAMEL – Service description – Stage 1
3GPP TS 23.078CAMEL Phase 4 – Stage 2
3GPP TS 23.278CAMEL Phase 4 – Stage 2 – IM CN Interworking
3GPP TS 29.078CAMEL Phase X – CAMEL Application Part (CAP) specification
3GPP TS 29.278CAMEL Phase 4 – CAP specification for IP Multimedia Subsystems (IMS)
3GPP TS 29.002Mobile Application Part (MAP) specification
WLAN Access:
3GPP TS 22.234 Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking
3GPP TS 23.2343GPP System to WLAN Interworking – System Description
3GPP TS 24.234 WLAN User Equipment (WLAN UE) to Network Protocols – Stage 3
3GPP TS 29.161Interworking between the PLMN supporting Packet based Services with WLAN Access and PDNs
3GPP TS 29.2343GPP System to WLAN Interworking – Stage 3
3GPP TS 32.252WLAN Charging
3GPP TS 33.234WLAN Interworking Security
CSICS: Circuit Switched IMS Combinational Services:
3GPP TS 22.279 Combined CS and IMS Sessions – Stage 1
3GPP TS 23.279 Combining Circuit Switched (CS) and IMS Services – Stage 2
3GPP TS 24.279 Combining Circuit Switched (CS) and IMS Services – Stage 3
Presence:
3GPP TS 22.141Presence Service – Stage 1 – Requirements
3GPP TS 23.141Presence Service – Stage 2 – Architecture and functional description
3GPP TS 24.141Presence service using the IP Multimedia (IM) Core Network (CN) subsystem – Stage 3
3GPP TS 26.141IMS Messaging and Presence – Media formats and codecs
3GPP TS 33.141 Presence service – Security OMA Presence Simple OMA Presence Simple V1.0.1 Approved Enabler
PoC: Push-to-talk over Cellular:
3GPP TR 23.979Push-to-talk over Cellular (PoC) Services – Stage 2
3GPP TS 32.272 Push-to-talk over Cellular (PoC) charging
And now, let’s get down to business.