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.

“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…

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

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

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):

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]."

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).

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:

— At this is the no-TLS way to configure it: not much to configure, actually.

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:

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.

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:

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.

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:

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.

Then the S-CSCF responds to the Register message by sending a 200 OK message. This message contains also a P-Associated-URIlist – 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:

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:

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:

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:

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:

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.