soa.docs 21.3 KB
Newer Older
Pekka Pessi's avatar
Pekka Pessi committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
/**@mainpage Sofia SDP Offer/Answer Engine

@section soa_meta Module Information

The Sofia @b soa module consists of an asynchronous SDP Offer/Answer engine
library. The interface to library is defined in <soa.h>.

@CONTACT Pekka Pessi <Pekka.Pessi@nokia.com>

@STATUS Core library

@LICENSE LGPL

@section soa_oveview Using soa engine

SIP uses SDP and a negotiation procedure known as "SDP
Offer-Answer Model" to establish the multimedia sessions. The
SDP Offer-Answer negotiation is specified in 
<a href="http://ietf.org/rfc/rfc3264.txt">RFC 3264</a>.

Pekka Pessi's avatar
Pekka Pessi committed
21 22 23 24 25 26 27
The soa engine is implemented in object-oriented manner. The default soa
object just implements the basic SDP negotiation and basic SIP call model. A
more complex soa object implementation can manipulate the call model and
initiate actions on behalf of application.

@section soa_model SDP Offer/Answer Model

Pekka Pessi's avatar
Pekka Pessi committed
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
The basic capabilities provided by Offer/Answer mechanism include
-# generating SDP offer (section 5)
-# processing SDP offer, generating SDP answer (section 6)
-# processing SDP answer (section 7)
-# modifying session (section 8)
-# indicating capabilities (section 9)

The offerer indicates its capabilities in the offer: 
- the media streams it wants to establish
- transport addresses it uses to receive by media streams 
  (IP addresses, port numbers, transport protocols) 
- the codecs used by particular streams
- codec parameters (for instance, codec profile used by H.263)

The answerer indicates which parts of the offer are acceptable to
it in the answer:
- the media streams it agrees to establish
- transport addresses answerer uses to receive by media streams 
- the codecs and codec parameters used by particular streams

Note that the capabilites indicate what the party generating the
SDP is prepared to receive. They can send anything the other end
accepts.

There may be other things, like encryption keys included in the
session description.

The advanced capabilities are required by more complicated negotiation
involving two or more offer-answer rounds. For instance, an extension known
as session <i>preconditions</i> is defined
<a href="http://ietf.org/rfc/rfc3312.txt">RFC 3312</a>.
59
Another example of two-phase negotiation is presented in RFC
Pekka Pessi's avatar
Pekka Pessi committed
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
3264 section 10.2, showing how a single codec can be selected. 

@section soa_motivation SOA Design 

Why to have simple interface? Is it not simple enough to include SDP offer
with your INVITE, and act on SDP answer in 200 OK?

Our design goal is to allow application to follow the simple call
model, regardless of the underlying complications - early
sessions, preconditions, session timers, 3rd party call control. 
In other words, we would like a have a simple "cooked" interface
toward naive applications even if the underlying call follows the
byzantine call model chosen by 3GPP.

@section soa_with_sip Using SDP Offer/Answer with SIP

Using SDP Offer/Answer with SIP is specified in 
<a href="http://ietf.org/rfc/rfc3261.txt">RFC 3261</a>, 
<a href="http://ietf.org/rfc/rfc3262.txt">RFC 3262 (100rel and PRACK)</a>, and
<a href="http://ietf.org/rfc/rfc3211.txt">RFC 3311 (UPDATE)</a>.

There is a @ref soa_sdp_oa_use_cases "separate page listing scenarios".

The rules for sending offers:
- offer may be sent in INVITE
- if there was no offer in INVITE, offer MUST be sent in first
  reliable response to INVITE
- offer may be sent in 100rel (reliable 1XX series response)
- offer may be sent in PRACK
- offer may be sent in UPDATE

PRACK may only be sent when an unacknowledged 100rel (reliable 1XX
series response) is received. UPDATE may be sent during early or
established dialog. 

Only one INVITE request may be pending within a dialog. Only one
non-INVITE request may be pending within a dialog (in one
direction): it is not possible to send UPDATE if no final response
has been received to PRACK.

100 101 102 103
If there is already an offer/answer exchange in progress, no offer
MUST be sent. Offer/answer exchange is in progress if offer has
been sent but no answer has been received, or if an offer has been
received but no answer has been generated.
Pekka Pessi's avatar
Pekka Pessi committed
104 105 106 107

The rules for sending answer:
- when offer is received with INVITE
  - answer MAY be sent with next end-to-end 1XX or 2XX response
108
  - answer MUST be sent in a reliable response (100rel or 2XX)
Pekka Pessi's avatar
Pekka Pessi committed
109 110 111 112 113 114 115
- when offer is received in 2XX response
  - answer MUST be sent in ACK
- when offer is received with 100rel response
  - answer MUST be sent with PRACK
- when offer is received with PRACK or UPDATE
  - answer MUST be sent with 2XX response to PRACK or UPDATE

116 117 118
Offer or answer in PRACK MUST be processed even if we have already
sent 2XX to INVITE.

Pekka Pessi's avatar
Pekka Pessi committed
119 120
The rules for receiving answer:
- if offer was sent in INVITE, first session description in any
121
  non-error response to INVITE is treated as the answer
Pekka Pessi's avatar
Pekka Pessi committed
122 123 124 125 126 127 128
- if offer was sent in 2XX response, session description in
  ACK is answer 
- if offer was sent in 100rel response, session description in
  PRACK is answer 
- if offer was sent in PRACK or UPDATE, session description in 
  2XX response is answer

129 130 131 132 133 134 135 136
Rules for situations when endpoint MUST ignore the SDP: 
- If offer was sent in INVITE, only the first session description in
  any non-error (1XX or 2XX) response to INVITE is processed, rest
  are ignored
- If no offer was sent in 2XX response to INVITE, SDP in ACK is ignored
- If no offer was sent in PRACK, SDP in response to it is ignored
- If no offer was sent in UPDATE, SDP in response to it is ignored

Pekka Pessi's avatar
Pekka Pessi committed
137 138 139 140 141 142 143 144 145
The re-INVITEs and UPDATEs are sent for two different purposes:
updating or modifying SIP state, or updating or modifying the
associated session. Session timer extension (not yet an rfc) is an
example of the first. Putting a call on hold, or adding video to
audio-only call is an example of the second. So, upon receiving
re-INVITE, there might be quite different things happening. The
application can just return a 200 OK with previous SDP, sometimes
it must indicate call being on hold and sometimes ask user for
permission (for adding video).
Pekka Pessi's avatar
Pekka Pessi committed
146 147 148 149 150 151

Rules for resolving glare (both endpoints trying to send offer at the same
time):
- if a offer is received while UAS has generated an offer, 
  it must be rejected (with SIP 491 response).

Pekka Pessi's avatar
Pekka Pessi committed
152 153
@section soa_use_cases SOA and SDP Offer/Answer Scenarios

Pekka Pessi's avatar
Pekka Pessi committed
154 155 156
Note that due to limitations in space
- soa_set_params() is referred as @c set_params
- soa_set_remote_sdp() is referred as @c set_remote
Pekka Pessi's avatar
Pekka Pessi committed
157 158 159 160
- soa_generate_offer() followed by soa_get_session_sdp() 
  is referred as @c gen_offer  
- soa_generate_answer() followed by soa_get_session_sdp() 
  is referred as @c gen_answer 
Pekka Pessi's avatar
Pekka Pessi committed
161 162
- soa_process_answer() is referred as @c proc_answer 

Pekka Pessi's avatar
Pekka Pessi committed
163
@subsection soa_uc_basic_out Basic Call Out
Pekka Pessi's avatar
Pekka Pessi committed
164 165 166 167 168 169 170 171

This is the "basic" outbound call model.

<pre>
       APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|----INVITE---->|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
172 173 174 175
 2	|		|--set_params-->|			|
 3      |		|---gen_offer-->|			|
 4	|		|		|			|
 5	|		|-------------------INVITE(sdp offer)-->|
Pekka Pessi's avatar
Pekka Pessi committed
176
 6      |		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
177 178 179 180 181 182 183 184 185 186 187 188 189 190 191
 7	|		|		|			|
 8      |		|		|     			|
 9      |		|< - - - - - - - - - - 180 Ringing - - -|
10      |< - - 180 - - -|		|			|
11      |		|		|			|
12      |		|<-------------------200(sdp answer)----|
13	|		|--set_remote-->|			|
14	|		|--proc_answer->|			|
15	|<-----200------|		|			|
16      |		|               | 			|
17      |		|----activate-->|			|
18	|<----active----|		|			|
19	|		|-------------------------ACK---------->|
20	|		|		|			|
21	|		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
192 193 194 195
22	|		|		|			|
        |		|		|			|
</pre>

Pekka Pessi's avatar
Pekka Pessi committed
196
@subsection soa_uc_basic_in Basic Call In
Pekka Pessi's avatar
Pekka Pessi committed
197 198 199 200 201 202 203 204 205

This is the "basic" inbound call model.

<pre>
       APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|		|<------------------INVITE(sdp offer)---|
 2      |		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
206
 3	|		|--set_remote-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
207 208 209 210 211 212 213 214 215
 4      |		|		|			|
 5	|<---INVITE-----|		|			|
 6      |		|		|			|
 7      |		|		|			|
 8	|- - -180- - - >|		|			|
 9	|		|- - - - - - - - - - 180 Ringing - - - >|
10      |		|		|			|
11      |		|		|			|
12	|-----200------>|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
216
13	|		|--set_params-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
217
14      |		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
218 219
15	|		|--gen_answer-->|			|
16	|		|               |			|
Pekka Pessi's avatar
Pekka Pessi committed
220 221 222 223 224 225 226 227 228 229 230
17	|<----active----|		|			|
18	|		|----activate-->|			|
19	|		|--------------------200 (sdp answer)-->|
20	|		|		|			|
21	|		|		|	 		|
22	|		|<------------------------ACK-----------|
23	|<-----ACK------|		|			|
24	|		|		|			|
	|		|		|			|
</pre>

Pekka Pessi's avatar
Pekka Pessi committed
231
@subsection soa_uc_basic_3p 3rd Party Call In 
Pekka Pessi's avatar
Pekka Pessi committed
232 233 234 235 236 237 238 239 240 241 242 243 244 245

The 3rd-party call model just reverses the O/A roles of callee and caller.

<pre>
 t     APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|		|<----------------------INVITE----------|
 2	|    		|		|			|
 3      |<---INVITE-----|		|			|
 4	|		|		|			|
 5	|		|		|			|
 6      |    		|		|			|
 7	|----200 OK---->|   		|			|
Pekka Pessi's avatar
Pekka Pessi committed
246
 8      |		|--set_params-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
247
 9      |		| 		|			|
Pekka Pessi's avatar
Pekka Pessi committed
248 249
10      |		|--gen_offer--->|			|
11	|		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
250 251 252 253 254
12      |		|		|			|
13      |		|----------------------200 (off) ------>|
14	|		|		|			|
15	|		|		|	 		|
16	|     		|<---------------------ACK (ans)--------|
Pekka Pessi's avatar
Pekka Pessi committed
255 256 257
17      |		|--set_remote-->|			|
18	|		|--proc_answer->|			|
19	|<----ACK-------|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
258 259 260 261 262 263
20	|<----active----|		|			|
21	|		|----activate-->|			|
22      |		|		|			|
        |		|		|			|
</pre>

Pekka Pessi's avatar
Pekka Pessi committed
264
@subsection soa_uc_early_out Callout with Early Media
Pekka Pessi's avatar
Pekka Pessi committed
265 266 267 268 269 270 271 272 273 274 275 276 277 278

It is possible to establish media session before call is completed. In this
case, the 180 Ringing contains the SDP answer. A copy of SDP answer is
included in the 200 OK response, too, because the 180 Ringing is not
acknowledged and it may be lost.

This is preferred to the basic call model above, as the endpoints has more
time to establish the media session.

<pre>
 t     APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|----INVITE---->|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
279
 2      |		|--set_params-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
280
 3	|		|               |			|
Pekka Pessi's avatar
Pekka Pessi committed
281 282
 4      |		|--gen_offer--->|			|
 5	|		|               |			|
Pekka Pessi's avatar
Pekka Pessi committed
283 284 285 286 287 288
 6      |		|		|			|
 7      |		|-------------------INVITE(sdp offer)-->|
 8	|		|		|			|
 9	|		|		|			|
10      |		|		|			|
11      |		|<-------------------180(sdp answer)----|
Pekka Pessi's avatar
Pekka Pessi committed
289 290 291
12      |		|--set_remote-->|			|
13	|<-----180------|--proc_answer->|	    		|
14	|   		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
292 293 294 295 296 297 298 299 300 301 302 303 304
15      |		|		|			|
16	|		|		|			|
17	|		|<-----------------200(copy of answer)--|
18	|	(copy is ignored)	|			|
19	|		|		|			|
20	|<-----200------|		|			|
21	|		|----activate-->|			|
22	|<----active----|		|			|
23	|		|-------------------------ACK---------->|
24	|		|		|			|
	|		|		|			|
</pre>

Pekka Pessi's avatar
Pekka Pessi committed
305
@subsection soa_uc_early_in Call In Establishing Early Media
Pekka Pessi's avatar
Pekka Pessi committed
306 307 308 309 310 311 312 313

The mirror of the previous scenario:

<pre>
 t     APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|		|<------------------INVITE(sdp offer)---|
Pekka Pessi's avatar
Pekka Pessi committed
314
 2      |		|--set_remote-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
315 316 317 318
 3	|<---INVITE-----|		|			|
 4      |		|		|			|
 5      |   		|		|			|
 6	|---180 Ring--->|   		|			|
Pekka Pessi's avatar
Pekka Pessi committed
319 320
 7      |		|--set_params-->|			|
 8      |		|--gen_offer--->| 			|
Pekka Pessi's avatar
Pekka Pessi committed
321
 9      |		|	     (Note 1)			|
Pekka Pessi's avatar
Pekka Pessi committed
322
10      |		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
323 324 325 326 327
11      |		|-------------------180 (sdp answer)--->|
12	|		|		|			|
13	|		|		|			|
14	|		|		|			|
15	|----200 OK---->|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
328 329 330
16	|		|--set_params-->|			|
17	|		|		|			|
18	|		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
331 332 333 334 335 336 337 338 339 340
19	|		|-----------------200 (copy of answer)->|
20	|		|----activate-->|			|
21	|<----active----|		|			|
22	|		|<------------------------ACK-----------|
23	|<-----ACK------|		|			|
24      |		|		|			|
	|		|		|			|
</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
Pekka Pessi's avatar
Pekka Pessi committed
341
by caller until the call is accepted (200 OK is sent towards caller).
Pekka Pessi's avatar
Pekka Pessi committed
342

Pekka Pessi's avatar
Pekka Pessi committed
343
@subsection soa_uc_100rel_out Call Out with PRACK
Pekka Pessi's avatar
Pekka Pessi committed
344 345 346 347 348 349 350 351 352 353 354

Here is second alternative establishing media session before call is
completed. In this case, the 180 Ringing contains the SDP answer. The 180
Ringing is now sent reliably. In other words, it is acknowledged by a PRACK
request.

<pre>
 t     APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|----INVITE---->|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
355
 2      |		|--set_params-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
356
 3	|		|               |			|
Pekka Pessi's avatar
Pekka Pessi committed
357 358
 4      |		|--gen_offer--->|			|
 5	|		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
359 360 361 362
 6      |		|		|			|
 7      |		|-------------------INVITE(sdp offer)-->|
 8	|		|		|			|
 9	|		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
363 364 365
10      |		|<-------------------183(sdp answer)----|
11      |		|--set_remote-->|			|
12      |		|--proc_answer->|			|
Pekka Pessi's avatar
Pekka Pessi committed
366
13	|<-----183------|		|	    		|
Pekka Pessi's avatar
Pekka Pessi committed
367
14	|   		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388
15      |		|-----------------------PRACK---------->|
16	|		|<--------------------200/PRACK---------|
17	|<--200/PRACK---|		|			|
18	|		|		|			|
19	|		|		|			|
20	|		|<--------------------180 Ringing-------|
21	|<-----180------|		|			|
22	|		|-----------------------PRACK---------->|
23	|		|<--------------------200/PRACK---------|
24	|<--200/PRACK---|		|			|
25	|		|		|			|
26	|		|		|			|
27	|		|<----------------------200 OK----------|
28      |<--200/INVITE--|		|			|
29	|		|----activate-->|			|
30	|<----active----|		|			|
31	|		|-----------------------ACK------------>|
32	|		|		|			|
	|		|		|			|
</pre>

Pekka Pessi's avatar
Pekka Pessi committed
389
@subsection soa_uc_100rel_in Call In with PRACK
Pekka Pessi's avatar
Pekka Pessi committed
390 391 392 393 394 395 396 397

The mirror of the previous scenario:

<pre>
 t     APPL	       NUA	       SOA		      REMOTE
	|		|		|			|
 0      |		|		|			|
 1	|		|<------------------INVITE(sdp offer)---|
Pekka Pessi's avatar
Pekka Pessi committed
398
 2      |		|--set_remote-->|			|
Pekka Pessi's avatar
Pekka Pessi committed
399 400 401 402
 3	|<---INVITE-----|		|			|
 4      |		|		|			|
 5      |   		|		|			|
 6	|-183 Progress->|   		|			|
Pekka Pessi's avatar
Pekka Pessi committed
403 404 405
 7      |		|--set_params-->|			|
 8      |		|--gen_answer-->|			|
 9	|		|		|			|
Pekka Pessi's avatar
Pekka Pessi committed
406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446
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. 

Pekka Pessi's avatar
Pekka Pessi committed
447 448 449 450 451 452 453
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.
Pekka Pessi's avatar
Pekka Pessi committed
454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718

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

Pekka Pessi's avatar
Pekka Pessi committed
719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773
@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>


Pekka Pessi's avatar
Pekka Pessi committed
774
*/