Whilst in a fixed network environment resources are generally available, in GRPS resources for video and audio streams need to be reserved on demand by the terminal. When it comes to forking, the resource reservation on the calling (A) side needs special attention.

Let's assume the following:

• user A is attached to the IMS via UMTS/GPRS;
• user B is registered to IMS from three terminals: B1, B2 and B3 and has set no further preferences (e.g. feature tags);
• terminal B1 supports only audio, whilst terminals B2 and B3 support audio and video; and
• user A wants to invite user B to a voice and video session.

User A would send out an INVITE, including SDP for one voice and one video stream.

The INVITE reaches the S-CSCF of B, which forks it in parallel to all three terminals of the user:

Based on their capabilities, all three terminals respond with a 183 (Session Progress) response, each of them creating a separate dialog:

We assume these three 183 responses are received by terminal A in the sequence as shown above. As terminal A is attached via GPRS, it now needs to reserve the related resources.

In the end only one of the three sessions (either with B1, B2 or B3) will be established. Therefore terminal A does not need to reserve independent resources for all three dialogs. At maximum it needs to reserve the resources that were indicated in the initial INVITE request (i.e. one audio and one video stream).

So for the first 183 response (from B1), terminal A would start resource reservation for one audio stream. When receiving the second 183 (from B2), it will modify the reserved resources (in GPRS: the media PDP context) to meet the requirements for a single (!) audio stream and a video stream. It is important that terminal A does not reserve two audio streams here - one is sufficient, as in the end anyhow only one media session will be established.

When receiving the third 183 (from B3), the resources fro audio and video have already been reserved, so no further resource reservation is needed.

In this exaple we now assume further that the user accepts the call from terminal B1, i.e. B1 sends out a 200 (OK) response for the INVITE. Upon receiving this, the S-CSCF starts cancelling the dialogs towards B2 and B3. Terminal A, when receiving the 200 (OK) from B1 will again modify the resources, this time dropping the reserved video stream, as this one cannot be served by B1 (see first 183 response).

• 3.7 – IMS Concepts - Sharing a single user identity between multiple devices
• 11.6 - An example IMS session - Resource Reservation

• 9.2.3 - Special requirements applying to forked responses

The network may decide to use a different realm, e.g. in the above case instead of "initially_provisioned_home_domain.com" it might use "imsbook.com". When challenging the user, the S-CSCF therefore sends back the following:

Upon receiving this, the UE now must use the received realm in all further Authorization headers. This means that the realm received from the network overrides the realm stored on the ISIM/derived from the USIM. The REGISTER request that the UE sends out next would therefore contain the following:

The UE always must use the latest received realm value, even if the network decides to change the realm during e.g. a re-authentication.

• 3.19.2 – IMS Concepts - Authentciation and Key Agreement (AKA)
• 10.6.2 – An Example IMS Registration - HTTP digest and 3GPP AKA

In order to give readers and implementors more guidance, TR 24.930 was created. This Technical Report includes example IMS session setup flows for different scenarios.

Although the TR is still work in progress, it already contains most of the necessary information. There are currently five flows, covering the detailed signalling for the following cases for IMS session establishment:

• Both endpoints need to reserve their resources
  e.g. both phones are connected over UMTS/GPRS to the IMS network
  
  
• Only the called endpoint needs to reserve resources
  e.g. the calling phone is attached via wireless LAN and the called phone is attached via UMTS/GPRS to the IMS network.
  
  
• Only the calling endpoint needs to reserve resources
  e.g. the calling phone is attached via UMTS/GPRS and the called phone is attached via DSL to the IMS network.
  
  
• The calling endpoint needs to reserve resources and the called endpoint is outside the IMS (Interworking Scenario)
  e.g. the calling phone is attached via UMTS/GPRS to the IMS network and the called phone is a SIP terminal in the internet, without being registered to an IMS network
  
  
• The calling endpoint is outside the IMS and the called endpoint needs to reserve resources (Interworking Scenario)
  e.g. the calling phone is SIP terminal in the internet, without begin registered to an IMS network and the called phone is attached via UMTS/GPRS to the IMS network

TS 24.228 - the outdated example call flows
As there are questions coming up on TS 24.228, which also contains example call flows, I give a short history of that spec and try to explain why one should not use it anymore.

When 3GPP started working on IMS on a protocol level, the new SIP RFC was still on its way and there were also many SIP extensions, that were under discussion during that time in IETF. In addition to that the IMS architecture also went through some changes, although the basics were settled.

In order to keep on track with the decisions made in other groups, 3GPP CT1 decided to create a document with example call flows, which was 3GPP TS 24.228. If your computer is slow and lacks memory, don't open it - it is a 800 pages word file, full of message sequence drawings and message contents. 24.228 is usually referred to as "the monster".

The example call flows were in fact very helpful in the beginning and helped a lot to derive the normative protocol specification for IMS from it. Also a lot of holes in the specifications were found there and could be fixed. Unfortunatley the specification grew and grew and at the same time IETF changed its SIP-related drafts frequently, which caused further changes in 24.228.

In the end the outcome did not justify the effort anymore and people stopped maintaining the example flows. The document itself still exists, but only in a 3GPP Release 5 version, i.e. it does officially not exist for Rel-6 and later releases.

But this does not stop people from looking into it - which is ok, as 24.228 still contains a lot of valuable information, the only thing is: one cannot trust the information in it to be up to date, i.e. it can be wrong. That's why the golden rule is: Don't trust 24.228 - best is not to look into it at all.

After seeing that example flows turn out to be a huge maintenance work, CT1 got reluctant to specify much more of them. Nevertheless there are some in the IMS Presence (TS 24.141), IMS Conferencing (TS 24.147) and IMS Messaging (TS 24.247) specs.

To get a frist impression and understanding of how session setup in IMS works, it is receommended to have a look into TR 24.930.

TS 24.228 should be avoided - it is not to date anymore and will not be further maintained.

If you are looking for the textual description of how SIP and SDP are used in IMS, then TS 24.229 is the right place to look at.

There are further specifications that show example call flows also for other protocols used in IMS (e.g. Diameter and COPS) - you can find a list of them here.

Both lists are very basic at the moment - they will be extended during the next weeks.

I intentionally did not list any IETF drafts - they can be more easily accessed from the IETF Drafts Tracker.

There are currently four major standards bodies that publish IMS related specifications and standards: 3GPP, IETF, OMA and ETSI TISPAN. This text gives you guidance on finding 3GPP and IETF specifications.

3GPP - The Third Generation Partnership Project

3GPP is divided into four Technical Specification Groups (TSGs), under which the so-called Working Groups (WGs) are organized. The technical work happens and is agreed in the WGs. The TSGs hold plenary meetings and give their final approval to the documents.

There are two types of documents that 3GPP specifies: Technical Specifications (TSs) and Technical Reports (TRs).

For IMS the majority of the work is happening in the following working groups:

• TSG SA WG1 "SA1" (Services / Requirements)
• TSG SA WG2 "SA2" (Architecture)
• TSG SA WG3 "SA3" (Security)
• TSG CT WG1 "CT1" (User Equipment - Core Network Layer 3 protocols)
• TSG CT WG3 "CT3" (Interworking with External Networks)
• TSG CT WG4 "CT4" (Network Internal Protocols)

On each of these working groups homepages a link points to "Document Area" and that is where all the TSs / TRs can be found.

An easier way to find 3GPP specifications is to go to the Specifications entry page - that is helpful if you already know the number.

Let's assume you are looking for 3GPP TS 24.299, which describes how SIP and SDP are used in the IMS on a protocol level. You go to the Specifications entry page, click on "24 series" (as you look for 24.229 and on the next page on TS 24.229. On this page you will find a long list of different versions of 24.229.

Other than e.g. IETF, 3GPP puts out its standards in releases. A release has a fixed scope and is specified within the time frame of one year (that's very optimistic) up to three years. At a certain point of completion the release gets frozen. After that, only essential corrections are allowed to that release.

The specification of IMS started in 3GPP Release 5 (Rel-5). Currently work is ongoing for Rel-7. The content of 24.229 is different in Rel-5 from Rel-6 and Rel-7. So you need to make sure that you know which Release of 3GPP and IMS you are looking for. Once you know that, you can always take the last entry under that release from the table.

Let's assume you want to get the newest version of 24.229, which at the time of writing this text is version 7.3.0. It still includes work in progress, but maybe you don't mind about that. So you click on "7.3.0" and a ZIP-File opens. The Word-File included in the ZIP is the document you are looking for.

The version numbering of 3GPP specs is not very difficult to understand and is by the way also explained in the foreword of most of the specs.

• The first digit represents the Release. If the work on a specification is still ongoing and has not stabilized to at least 80%, the first digit is set to "0", "1" or "2". The version is approved and under change control, once the number is greater than "2".
• The second digit is incremented after every TSG plenary meeting at which a change to the specification in that release has been approved.
• And the third digit is different from "0" only when smaller editorial changes have been introduced, that did not touch the technical content of the specification.

IETF - The Internet Engineering Task Force

The IETF is not directly working on IMS, but specifies practically all base protocols that are used within the IMS. Most important for the IMS is the Session Initiation Protocol (SIP) with most of its extensions. But also a large number of other protocols (such as Diameter, COPS or MEGACO) are used by 3GPP for the IMS.

IETF is organized in different Areas and under those we find the Working Groups (WGs). The most important WGs for IMS related work are

• sip - Session Initiation Protocol
• sipping - Session Initiation Proposal Investigation
• simple - SIP for Instant Messaging and Presence Leveraging Extensions

There are also other groups that have impact on IMS and SIP, such as e.g. xcon (Centralized Conferencing), ecrit (Emergency Context Resolution with Internet Technologies) or enum (Telephone Number Mapping).

Specifications are first submitted as individual drafts to the WG. The WG can adopt the draft, then it becomes a working group draft. After the WG has consensus that a draft is completed, it approves it (WG approval). It is then reviewed by the Area Directors and finally checked again by the highest body in the IETF, the IESG (IESG approval). After IESG approval the draft becomes a so-called "Request for Comments" (RFC) and gets a number assigned. Only very few of these RFCs make it to a real IETF standard. Within the industry RFCs nevertheless are seen as (de-facto) standards.

The above is a very simplified description of the IETF standards process. More detailed information can be found here.

Looking for Internet Drafts (I-Ds)

Let's assume you look for the newest draft on GRUU (the SIP Global Routable User Agent URI). Go to the I-D Tracker and put into the Filename filed "gruu" and you will get to see this page, which (at the moment of writing this) tells you that there are several GRUU drafts around. The main one is draft-ietf-sip-gruu-07.txt.

Looking for Request for Comments (RFCs)

Once an I-D has made it through IESG approval it becomes an RFC and gets assigned a number. If you know the number of the RFC you are looking for, then the easiest way to access it is to type the following into your web browsers address field:

Of course you have to replace "$number$" with the number of the RFC you are looking for. Just try it with the basic SIP RFC 3261. Also look at the left side of the header of the RFC, there you see that it "obsoletes" RFC 2543, which was the first version of the SIP RFC. Other than 3GPP, IETF does not have version numbers for their approved specifications. In order to change an existing RFC, a new RFC number needs to be assigned.

3GPP keeps a very detailed list of IETF specifications, towards which it has dependencies. Most of these dependencies are based on the IMS, but also GPRS has quite a lot of them.

In Summary:

• 3GPP Specifications entry page - if you know the number of the specification you are looking for.
  
  
• 3GPP Organisation - if you know the Working Group that is maintaining the specification.
  
  
• IETF I-D Tracker - if you are looking for an internet draft.
  
  
• http://www.ietf.org/rfc/rfc$number$.txt - if you know the number of the RFC you are looking for.
  
  
• IETF Working Group Directory - if you know the working group that is working on the RFC.
  
  
• 3GPP List of Dependencies towards the IETF

• Add this article to your del.icio.us links
• E-Mail this article to another person
• E-Mail the author
• Technorati Tags: ims ipmultimediasubsystem 3gpp ietf sip standards specification rfc standardisation internet-draft