IMS/SIP - Overall Data Path Home : www.sharetechnote.com
I was sitting in a couple of IMS training course. I noticed the most common questions from both instructors and audience was "How my IMS voice/data get delivered to the other side in this and that kind of situation ?".
The answer never ends and question never stops.. easily eats up the most of training session.
It may be an important question and answer and necessary to understand the details of IMS mechanism, but not easy to come out with "Short and Clear" answer to this kind of questions because there can be so many variation in each cases.
So my intention is not to give you any single solid answer for "IMS Data Path", but to give you some guide line (or logics of thinking) on IMS data delivery.
First, I want you to get yourself familiar with the following diagram.
There are several common rules which can help you to get the answer for data path by yourself.
i) All LTE data and all LTE signaling message has to go through eNodeB at first step.
ii) All LTE data (user data) has to go through S-GW and P-GW. (Note : Both IMS Signaling or IMS Data is regarded as a user data in terms of LTE network. This is an important point that would clear a lot of confusion).
iii) ALL IMS Signaling Message has to go through P-CSCF
iv) IMS Data (e.g, Voice, Video) may not go through any CSCF.
v) For every IMS registration, the IMS message (registration message) go through P-CSCF and S-CSCF talk to HSS to check if the user is IMS service subscriber or not.
vi) When you (IMS phone, UA1) want to talk to another IMS phone (UA3), IMS core has to check if the other party (UA2) is IMS subcriber and is now registered to IMS core. It is I-CSCF's job to check all these status.
vii) When you (IMS phone, UA1) want to talk to another phone, first your network should check whether the other party (phone) is IMS capable phone or a home phone or just a conventional IP phone, it is ENUM's job to check about this kind of status.
viii) Whenever a service is initiated (requested by a UA), CSCF would talk to PCRF if the requested service is allowed for the user.
With these rules in mind (I am pretty sure that I would have missed rules), please print out the diagram above and set a specific scenario (e.g, 'I want to make a call from UA1 to UA2' or from UA1 to UA3 etc) and draw the lines for data path. Don't worry about getting wrong.. you may be wrong in a couple of points but at least more than 70% you would be right if you apply the rule listed above.
This section will show you about overall procedure of SIP communication.
Take a look at following illustration. I put two imaginary domains and call them ims.myims.com and ims.yourims.com respectively. This illustration shows the overall registration for the case where two User Agents (UA1, UA2) are already registered in the registration system. Usually we call the registration agent in SIP communication system as Registra.
In the illustration above, we think of the case where UA1 make a call to UA2.
(1) UA1 make a SIP call to UA2. This Call request first reaches to the proxy (a kind of coordinator. Similar to CSCF in IMS)
(2) Proxy queries about the information about UA1, UA2 to the data base (HSS) which contains all the registration information and policies for all the UAs in the domain.
(3) Proxy recieves the informations from HSS.
(4) If UA2 has already been registered and policy allows the communication between UA1 and UA2. The Proxy send Alert to UA2 saying "Hey.. somebody want to talk to you !".
(5) If UA2 is ready to talk, it send 'Confirmation' to Proxy.
(6) Proxy notifies the confirmation to UA1.
(7) Now call setup is complete, and UA1 and UA2 talk to each other.
Now let's think of a little bit more complicated than previous case. As you see in the following illustration, two different domains are invovled in this example. a UA(UA4) try to make a call to a UA(UA1) which belongs to different domain.
Now let's look into each steps of communication setup.
(1) UA4 in domain ims.yourims.com make a SIP call to UA1 in domain ims.myims.com. This Call request first reaches to the proxy. The broxy find out that the requested destination is out side of the current domain.
(2) The proxy (proxy2) queries DNS server to find the address of proxy of the destination domain.
(3) Proxy2 get the reply from DNS. Now Proxy 2 know the address of the proxy (proxy 1) in destination domain.
(4) Proxy2 transfer the call setup request to Proxy 1 saying "Somebody(UA4) in my domain want to talk to somebody(UA1) in your domain".
(5) Proxy1 queries about the information about UA1 to the data base (HSS) which contains all the registration information and policies for all the UAs in the domain.
(6) Proxy recieves the informations from HSS.
(7) If UA1 has already been registered and policy allows the communication between UA1 and UA4. The Proxy send Alert to UA1 saying "Hey.. somebody want to talk to you !".
(8) If UA1 is ready to talk, it send 'Confirmation' to Proxy.
(9) Proxy1 notifies the confirmation to Proxy2.
(10) Proxy2 relays the confirmation to UA4
(11) Now call setup is complete, and UA4 and UA1 talk to each other.