SIP call flows : https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-99.

html

Call hold : https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-01.html

consultation hold : https://www.tech-invite.com/fo-sip/tinv-fo-sip-service-02.html

+sip.rendering

Music on hold

Scenario : user A & B are on call & when B puts A on hold A should hear some music when on hold. &
then again user B unholds user-a.

A sends invite msg to b, b sends 18R, then sends 200 ok & user sends ACK & RTP is shared between
both parties.

Now B puts a on hold by sending re-invite, A sends 200 ok & B sends ACK for re-invite. & there is no RTP
between A & B now.

Now user b wants that a should hear a music when user B puts user A on hold, hence user B will send
REFER request to Music server, where refer to header will have address of user A. Music server will
send 202 Accepted for refer msg. then it will send notify msg to user-b that it has started working on
task in refer request provided by B. user B will send 200 ok for this notify msg.

Now music server will send invite to user-A in which it will use replaces header (replaces to B). means A
is already in session with B. so music server is saying to user-a that now u replace B & establish session
with me(music server). User –a sends 200 ok & music server will send ACK. & now music starts playing
means RTP is established between Music server & A.

Since user-A is having session with music server, it will send Bye to user-B, user B sends 200 ok.

Now Music server will again notify user-B saying that it has completed the task given in refer msg. &
user-b sends 200 ok for notify.

Now user-B again sends Invite to user-A to unhold call & here it uses replaces header (replaces to music
server). User a sends 200 ok, user B sends ACK.

Since user-A has again established call with user-B it will end its session with Music server by sending Bye
to Music server, Music server sends 200 ok.

No.of transaction : (f1,f2,f3)+(f4)+(f5,f6)

Deep dive :

st
In refer msg user-b will send refer to, refer by required header & replaces contain information of 1
dailogue.

In second notify request music server will also send the info about user A to user-B which it has got from
200 ok from user-A (F13) which establishing session with it.

In f12 of invite it will be same as refer msg only refer to will not be there.
Automaton means the UE which is sending the request is a machine like a music server, conference
server etc.

Sip.byless means user agent that is sending the request cannot send bye.

"sip.byeless", which indicates that a SIP user agent (UA) is not

capable of terminating a session itself (for example, in some

announcement or recording services, or in some call centers) in

which the UA is no longer interested in participating;

Sip.rendering = no means here media is not rendering.

Call forwarding :

1. Unconditional : in this case user B has enabled unconditional forwarding towards C. means when
ever A makes call to B, it will always go to C.

Conditional
----------------------------------------------------------------------------------------------------------------
Here in all the 3 call flows where proxy sends the invite msg, there is a history info header present in it
which says contains address of all the users presnt in the call flow like a,b & c.

4 methods for call hold. Any 1 can be used

---------------------------------------------------------------------------------------------------------------------------

Call tranfer unattended

Here replaces has dailogue id between B & C.

Here sip frag means sip msg is fragmented.

nd
In 2 notify sip/2.0 200 ok means it is carrying the 200 ok which user C has sent to User-a.

--------------------------------------------------------------------------------------------------------------------------

call transer flow :

attended call transfer.

scenario : user-a calls B, session is established between both of them. Now user-a wants to communicate
with C, but doest not have its address, But user-B has address of user-c. so userB will bring user-a &
user-c into a session & then get out of that session himself.

user a establishes call with user b, then puts it onhold, user b establishes call with user-c then puts it on
hold. now user b sends reffer to user-a & in reffer always remember there is a method in which a tashk is
given, here task is to send invite msg to c. address of c is mentioned in reffer to header.

1st notify says the progress of reffer msg.

then user a sends invite to user -c where it mentions replaces to b, that y c sends bye to user b .

2nd notify informs that user a has completed the task given by B.

unattended call transfer

scenario : user A & user B is in a call, Now user A wants to call user-C but doesnot have its address,
user-b has address of user c, so user-b here will directly send the address of user-c, & user a will establish
a session with user-c.

Call tranfer unattended

Here replaces has dailogue id between B & C.
Here sip frag means sip msg is fragmented.
nd
In 2 notify sip/2.0 200 ok means it is carrying the 200 ok which user C has sent to User-a.

call forking

Call forking
Forking basically means splitting. (main parameters/header is branch & tag)
Forking basically means when UAC sends single request to proxy server, it forwards this request to
multiple end points. There are 2 types parallel forking & serial forking.

Parallel call forking

Here in above fig.

UAS is registered via 3 devices 1. Desktop, 2. Phone 3. Softphone
So when UAC contacts UAS via proxy server, it splits the request & forwards to all 3 devices.
Now all 3 devices receives invite message & sends 180 ringing to proxy server. Proxy server accepts
only 1 response from any 3 of them. For rest 2 its sends cancel request.
RTP is established only with 1 device that is selected by proxy server.
Point to note : here our proxy has divided the single request into multiple branches. 1 invite is sent
nd rd
to desk, 2 to phone & 3 to soft phone. Now how will proxy identify response from each devices ?
so that is with the help of branch-id. When forwarding request to multiple devices it will add a
branch-id in INVITE REQUEST & then forward it.
Serial call forking

In case of serial call forking , proxy will first send request to device which has high priority. Priority is
set by devices while registration. Q value is used to set priority of devices. Value of Q ranges from 0-1
where 1 has highest priority.

BRANCH-ID (parallel forking case)

To distinguish between different responses proxy server uses different branch-id header in INVITE
message. Now lets consider a case where 2 devices sends 200ok at the same time. Now question is
whom will proxy choose?. Proxy will choose on the basis of Q value which is mentioned by devices
while registering. Based upon Q value proxy will forward 200 ok response to UAC from the device
which will have high Q value. Then Ack will be sent by UAC & RTP session is established only with 1
device. Proxy server will send cancel request to rest devices.
Brach-id helps to differentiate between fork reposes for its respective fork request.
Branch-id is present in VIA header.
Why branch-id is always present in VIA header? Why not is other header?
Answer: because when UAS sends responses its uses VIA header to send back responses. Hence
branch-id is present in VIA header.
Branch-id starts with Z9HG4BK. These are called 7 magic cookies. It may end with any random
characters.

Tags
Now branch-id is added by proxy server & it helps it to distinguish response. But how will UAC know
which device has send request. So here TAG is used to differentiate.

Imp point : Proxy server never adds tag, only when they send final response then they will add tag.
 Question from testing point of view
When proxy sends ACK for unsuccessful response then the branch-id will be same as the one in
invite.
When proxy sends ACK for successful response then the branch-id is different from the one in Invite.

IMS

architecture & interface

node function

call flow

register, v2v, announcement, ims 2 PSTN, PSTN to ims, emenrgency, conference, roaming reg, roaming
call flow.