| permalink | related link |
( 2.9 / 1074 )SIP RFC 3261 defines the possibility that an INVITE request can be sent in parallel to different destination UEs (parallel forking). This can be the case if the called user is registered from several terminals at the same time, e.g. from a mobile phone, a laptop and a fixed phone. In IMS the possibility for a user to be registered from multiple terminals at the same time was introduced in IMS Rel-6.
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.
---INVITE B---->
m=audio 3458
m=video 3400
The INVITE reaches the S-CSCF of B, which forks it in parallel to all three terminals of the user:
---INVITE B1---->
m=audio 3458
m=video 3400
---INVITE B2---->
m=audio 3458
m=video 3400
---INVITE B3---->
m=audio 3458
m=video 3400
Based on their capabilities, all three terminals respond with a 183 (Session Progress) response, each of them creating a separate dialog:
<--183 from B1---
m=audio 4010
m=video 0 <-- no support for video
<--183 from B2---
m=audio 7070
m=video 7072
<--183 from B3---
m=audio 9598
m=video 9600
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).
Simplified call flow
A S-CSCF of B B1 B2 B3
--INVITE B----> --INVITE B1-->
m=audio 3458 m=audio 3458
m=video 3400 m=video 3400
------INVITE B2------>
m=audio 3458
m=video 3400
------INVITE B3------------->
m=audio 3458
m=video 3400
<-183 from B1-- <--183 from B1--
m=audio 4010 m=audio 4010
m=video 0 m=video 0
[A starts resource reservation for audio]
<-183 from B2-- <--183 from B2--------
m=audio 7070 m=audio 7070
m=video 7072 m=video 7072
[A adds video to the reserved resources]
<-183 from B3-- <--183 from B3----------------
m=audio 9598 m=audio 9598
m=video 9600 m=video 9600
[A does not need to change its resource reservation]
[several other messages may follow, such as PRACK, UPDATE and 180]
<--200 from B1-- <--200 from B1--
[A changes reserved resources to audio only]
---ACK to B1----> ---ACK to B1---->
--CANCEL to B2------->
<--200 for CANCEL----
<--497 from B3-- <--497 for INVITE----
---ACK---------> ---ACK-------------->
--CANCEL to B3------------->
<--200 for CANCEL-----------
<--497 from B2-- <--497 for INVITE-----------
---ACK---------> ---ACK---------------------->
Related Chapters in the IMS Book:
- 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
Add to del.icio.us – E-Mail to another person – E-Mail the author
Technorati Tags: ims sip forking resourcereservation
| permalink | related link |
( 2.8 / 743 )TS 24.229 version 7.4.0 just came out. It includes the latest approved changes to the specification.
| permalink | related link |
( 3 / 526 )During IMS registration the UE reads a public user identity and the realm from the ISIM (or derives them from the USIM, if no ISIM is available), puts them into the Authorization header and sends it within the initial REGISTER request to the S-CSCF.
REGISTER sip:initially_provisioned_home_domain.com SIP/2.0
Authorization: Digest username="dragonslayer@home1.fr",
realm="initially_provisioned_home_domain.com",
nonce="", uri="sip:initially_provisioned_home_domain.com",
response=""
[only relevant headers are shown]
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:
SIP/2.0 401 Unauthorized
WWW-Authenticate: Digest realm="imsbook.com",
nonce={noncevalue}, algorithm=AKAv1-MD5
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:
REGISTER sip:initially_provisioned_home_domain.com SIP/2.0
Authorization: Digest username="dragonslayer@home1.fr",
realm="imsbook.com",
nonce="{received-nonce-value}",
uri="sip:initially_provisioned_home_domain.com",
response="{calculated-response-value}"
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.
Related Chapters in the IMS Book:
- 3.19.2 – IMS Concepts - Authentciation and Key Agreement (AKA)
- 10.6.2 – An Example IMS Registration - HTTP digest and 3GPP AKA
Add to del.icio.us – E-Mail to another person – E-Mail the author
Technorati Tags: ims aka security realm authentication digest
| permalink | related link |
( 3.1 / 338 )During the last year the procedures for IMS session establishement were changed significantly in 3GPP. For a reader, who is not familiar with all the possible scenarios or is only looking for one of them, the procedures described in TS 24.229 (subclauses 5.1.3, 5.1.4 and clause 6) might be complicated to understand.
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.
Summary:
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.
Add to del.icio.us – E-Mail to another person – E-Mail the author
Technorati Tags: 24930 ims example callflow protocol voip sip sdp 24229 3gpp session
| permalink | related link |
( 3.2 / 371 )Next
Search
