Forking and Resource Reservation in IMS

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

Jad Decompiler Plug-in for Eclipse

JAD Eclipse is an eclipse plug-in for the JAD Decompiler. The following is a quick description of how to setup JAD Eclipse (assuming you already have eclipse setup).
Download the latest version of JAD decompiler and set modify your path to add JAD_HOME directory.
Download the latest version of JAD Eclipse from the link shown above and extract it to your eclipse plugins directory.
Restart eclipse and configure JAD as follows
In eclipse, go to - Window->Preferences->Java->JadClipse
Set Path to decompiler to "jad" (jad is already in your path).Click Apply.This is the basic setup for running JAD Eclipse. You will be able to look in to you library classes by simply clicking on the class file, or the class in the type hierarchy. If you are in the J2EE perspective, you can open up you jar files and look into those class files too. It is up to you to decide how you want to go. By the way, JAD eclipse also has a lot of additional customizations available, which can be seen under JAD Eclipse preferences in Eclipse.