soa.docs

sip协议栈

@subsection soa_uc_100rel_in Call In with PRACK

The mirror of the previous scenario:

<pre>
 t     APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|		|<------------------INVITE(sdp offer)---|
 2      |		|--set_remote-->|			|
 3	|<---INVITE-----|		|			|
 4      |		|		|			|
 5      |   		|		|			|
 6	|-183 Progress->|   		|			|
 7      |		|--set_params-->|			|
 8      |		|--gen_answer-->|			|
 9	|		|		|			|
10      |		|-------------------183 (sdp answer)--->|
11      |		|		|			|
12      |		|<----------------------PRACK-----------|
13      |<----PRACK-----|		|			|
14	|		|---------------------200/PRACK-------->|
15	|		|		|			|
16      |--180 Ringing->|   		|			|
17      |		|---------------------180 Ringing------>|
18	|		|		|			|
19      |		|<----------------------PRACK-----------|
20      |<----PRACK-----|		|			|
21	|		|---------------------200/PRACK-------->|
22      |		|		|			|
23      |		|		|			|
24      |		|		|			|
25      |----200 OK---->|		|			|
26      |		|----activate-->|			|
27      |<----active----|		|			|
28      |		|---------------------200/INVITE------->|
29      |		|		|			|
30      |		|<-----------------------ACK------------|
31      |<-----ACK------|		|			|
32      |		|		|			|
        |		|		|			|
</pre>

<b>Note 1:</b> the user expectation (set by ordinary telephone) here is that
callee sends a ringing tone towards caller and discards any media sent by
callee until the call is accepted at t=26 (200 OK is sent towards caller).

The application starts to alert user at t=13 when it knows that the
media session has been successfully established.

*/

/**
@page soa_sdp_oa_use_cases Use Cases for SIP and SDP Offer/Answer

This page contains a list of use cases or call scenarios for SIP and SDP
Offer/Answer. 

There are a few call scenarios that we expect to see when dealing with more
telephone-like side of SIP: 
- calling to existing PSTN networks (early session)
- doing resource reservations
- calling to 3G IMS
- call hunting
- having external party setting up your call, etc.

@section soa_use_case_1 Case #1: Basic Call

This is the basic SIP call model with the most simple offer-answer exchange.

<pre>
	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|			|
	|< - - 180 Ringing - - -|
	|			|
	|			|
	|<----200 (answer)------|
	|----------ACK--------->|
	|			|
	|			|
</pre>

@section soa_use_case_2 Case #2: Early Media

Another case, slightly more complex. The SDP answer is sent with
180 Ringing in order to establish an "early session". B might
not be a SIP phone, but a gateway to PSTN, for instance. Using this
"early session" B can play tones like "burr-burr" or "the
subscriber you tried to reach is not in the coverage...":

<pre>
	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|			|
	|<----180 (answer)------|
	|			|
	|			|
	|<----200 (answer')-----|
	|----------ACK--------->|
	|			|
	|			|
</pre>

After receiving answer in 180 Ringing, A simply ignores SDP in
subsequent responses.

Nothing special here, right? But SIP is not so simple,
unfortunately. There are hairy cases because of "early sessions",
"forking", "preconditions" and other reasons.

Now lets go through some hairy cases.

@section soa_use_case_3 Case #3: Early Dialog, Early Media

This case is a call using 100rel, early dialog and early media. It
is used when the session should be established before call alerts.

<pre>
	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|<----183 (answer)------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|
</pre>

@section soa_use_case_4 Case #4: UPDATE with Offer

This is a call model with two rounds of offer/answer and 100rel. 
It can be used, for instance, when the endpoints have to make sure
that there are enough network capacity for the call to succeed. 
They can establish a new radio bearer, for instance, before
progressing with the call. The initial offer would contain SDP
attribute "inactive", the second "sendrev":

<pre>
	A		        B
	|			|
	|----INVITE (offer)---->|
	|			| 
	|			| 
	|<----183 (answer)------| 
	|--------PRACK--------->|
	|<-----200/PRACK--------|
	|			|
	|			|
	|----UPDATE (offer2)--->|
	|<-200/UPDATE (answer2)-|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|
</pre>


@section soa_use_case_5 Case #5: 2nd Offer in PRACK

Alternative 1 to above, two rounds of offer/answer and 100rel, no
UPDATE. It can used, for instance, when caller wants to make sure
there is only one audio or video codec that is used during the
call. The initial offer would contain SDP attribute "inactive";
the second "sendrev":

<pre>
	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|<----183 (answer)------|
	|-----PRACK(offer2)---->|
	|<--200/PRACK(answer2)--|
	|			|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|
</pre>


@section soa_use_case_6 Case #6: Callee Making 2nd Offer 

Alternative 2 to above: two rounds of offer/answer and 100rel, but
now it is B who wants to do two rounds and initiates second
Offer-Answer exchange:

<pre>
	A		        B
	|			|
	|----INVITE (offer)---->|
	|			|
	|<----183 (answer)------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---UPDATE (offer2)----|
	|-200/UPDATE (answer2)->|
	|			|
	|<---------180----------|
	|--------PRACK--------->|
	|<-----200/PRACK------->|
	|			|
	|			|
	|<---------200----------|
	|----------ACK--------->|
	|			|
	|			|
</pre>


@section soa_use_case_7 Case #7: 3GPP Call Model

Here is a third alternative, know as "3GPP call model", where
there is not 2 but 3 offer-answer rounds, allowing A and B to do
precise resource reservations after they have agreed on media,
codecs and transport addresses used during the call:

<pre>
        	A		        B
        	|			|
        	|----INVITE (offer)---->|
        	|			| 
        	|			| 
        	|<----183 (answer)------| 
        	|-----PRACK(offer2)---->|
        	|<--200/PRACK(answer2)--|
        	|			|
        << resource reservations are done now >>
        	|			|
        	|----UPDATE (offer3)--->|
        	|<-200/UPDATE (answer3)-|
        	|			|
        	|<---------180----------|
        	|--------PRACK--------->|
        	|<-----200/PRACK------->|
        	|			|
        	|			|
        	|<---------200----------|
        	|----------ACK--------->|
        	|			|
        	|			|
</pre>


@section soa_use_case_8 Case #8: Forking

Now, another complication. Here B has two terminals, let say,
fixed (B1) and mobile (B2) phone, both alert when B receives a
call using procedure known as forking:

<pre>
	A		   B's proxy		B1		B2
	|			|		|		|
	|----INVITE (offer)---->|		|		|
	|			|-INVITE (off)->|		|
	|			|-----------INVITE (off)------->|
	|			|		|		|
	|			|<--180 (ans1)--|		|
	|<------180 (ans1)------|		|		|
	|			|		|		|
	|			|<----------180 (ans2)----------|
	|<------180 (ans2)------|		|		|
	|			|		|		|
	|			|		|		|
	|			|<----------200 (ans2')---------|
	|<------200 (ans2')-----|		|		|
	|			|----CANCEL---->|		|
	|			|<--200/CANCEL--|		|
	|			|<-----487------|		|
	|			|		|		|
	|----------ACK----------------------------------------->|
	|			|		|		|
	|			|		|		|
</pre>

Here we have two calls initially established, but the call to B1
along with "early session" is should be dropped when B2 picks up
the call (and 200 OK is returned).

@section soa_use_case_9 Case #9: 3rd Party Call Control

Now something different: 3rd party call model, where "C"
establishes the call:

<pre>
	A		        C		        B
	|			|			|
	|<-------INVITE---------|			|
	|			|			|
	|			|			|
	|------200 (offer)----->|  	  		|
	|			|----INVITE (offer)---->|
	|			|			|
	|			|			|
	|			|<-----200 (answer)-----|
	|<-----ACK (answer)-----|			|
	|			|     			|
	|			|----------ACK--------->|
	|			|			|
</pre>

@section soa_use_case_10 Case #10: Upgrade Session with Re-INVITE

The session is upgraded: a new media is added to the session. 

<pre>
	A		        B
	|			|
	|----INVITE (offer1)--->|
	|			|
	|			|
	|< - - 180 Ringing - - -|
	|			|
	|			|
	|<----200 (answer2)-----|
	|----------ACK--------->|
	|			|
	|			|
	|			|
	|			|
	|----INVITE (offer2)--->|
	|			|
	|<----200 (answer2)-----|
	|----------ACK--------->|
	|			|
	|			|
</pre>

@section soa_use_case_10 Case #10: Upgrade Session with Re-INVITE

The session upgraded is rejected.

<pre>
	A		        B
	|			|
	|----INVITE (offer1)--->|
	|			|
	|			|
	|< - - 180 Ringing - - -|
	|			|
	|			|
	|<----200 (answer2)-----|
	|----------ACK--------->|
	|			|
	|			|
	|			|
	|			|
	|----INVITE (offer2)--->|
	|			|
	|<---------488----------|
	|----------ACK--------->|
	|			|
	|			|
</pre>


*/