Offer/Answer. There are a few call scenarios that we expect to see when dealing with moretelephone-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 CallThis 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 MediaAnother case, slightly more complex. The SDP answer is sent with180 Ringing in order to establish an "early session". B mightnot be a SIP phone, but a gateway to PSTN, for instance. Using this"early session" B can play tones like "burr-burr" or "thesubscriber 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 insubsequent 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 MediaThis case is a call using 100rel, early dialog and early media. Itis 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 OfferThis is a call model with two rounds of offer/answer and 100rel. It can be used, for instance, when the endpoints have to make surethat there are enough network capacity for the call to succeed. They can establish a new radio bearer, for instance, beforeprogressing with the call. The initial offer would contain SDPattribute "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 PRACKAlternative 1 to above, two rounds of offer/answer and 100rel, noUPDATE. It can used, for instance, when caller wants to make surethere is only one audio or video codec that is used during thecall. 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, butnow it is B who wants to do two rounds and initiates secondOffer-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 ModelHere is a third alternative, know as "3GPP call model", wherethere is not 2 but 3 offer-answer rounds, allowing A and B to doprecise 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: ForkingNow, another complication. Here B has two terminals, let say,fixed (B1) and mobile (B2) phone, both alert when B receives acall 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 B1along with "early session" is should be dropped when B2 picks upthe call (and 200 OK is returned).@section soa_use_case_9 Case #9: 3rd Party Call ControlNow 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-INVITEThe 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-INVITEThe session upgraded is rejected.<pre>	A		        B	|			|	|----INVITE (offer1)--->|	|			|	|			|	|< - - 180 Ringing - - -|	|			|	|			|	|<----200 (answer2)-----|	|----------ACK--------->|	|			|	|			|	|			|	|			|	|----INVITE (offer2)--->|	|			|	|<---------488----------|	|----------ACK--------->|	|			|	|			|</pre>*//** @typedef struct soa_session soa_session_t;@brief "soa" session object. The @soa session object is responsible for@ref soa_with_sip "SDP offer/answer negotiation"defined in @RFC3264. The session object is used tostore the SDP template from user, remote SDP received from the network andthe negotiation result, local SDP.@par Functions used to create, copy and destroy "soa" session objects:@codesoa_session_t *soa_create(char const *name, su_root_t *, soa_magic_t *);soa_session_t *soa_clone(soa_session_t *, su_root_t *, soa_magic_t *);void soa_destroy(soa_session_t *);@endcode@par Functions used to set and get parameters for "soa" session objects:@codeint soa_set_params(soa_session_t *ss,                   tag_type_t tag, tag_value_t value, ...);int soa_get_params(soa_session_t const *ss,                    tag_type_t tag, tag_value_t value, ...);tagi_t *soa_get_paramlist(soa_session_t const *ss,                          tag_type_t tag, tag_value_t value, ...);@endcode@par Functions used to obtain status information from "soa" session objects:@codeint soa_error_as_sip_response(soa_session_t *soa,                               char const **return_phrase);char const *soa_error_as_sip_reason(soa_session_t *soa);int soa_get_warning(soa_session_t *ss, char const **return_phrase);@endcode@par Functions used to store and retrieve SDP descriptions: @codeint soa_set_capability_sdp(soa_session_t *ss,                            struct sdp_session_s const *sdp,                           char const *str, issize_t len);int soa_get_capability_sdp(soa_session_t const *ss,                           struct sdp_session_s const **return_sdp,                           char const **return_sdp_str,                           isize_t *return_len);int soa_set_remote_sdp(soa_session_t *ss,                        struct sdp_session_s const *sdp,                       char const *str, issize_t len);int soa_get_remote_sdp(soa_session_t const *ss,                       struct sdp_session_s const **return_sdp,                       char const **return_sdp_str,                       isize_t *return_len);int soa_clear_remote_sdp(soa_session_t *ss);int soa_get_remote_version(soa_session_t const *ss);int soa_set_user_sdp(soa_session_t *ss,                      struct sdp_session_s const *sdp,                     char const *str, issize_t len);int soa_get_user_sdp(soa_session_t const *ss,                     struct sdp_session_s const **return_sdp,                     char const **return_sdp_str,                     isize_t *return_len);int soa_get_user_version(soa_session_t const *ss);int soa_get_local_sdp(soa_session_t const *ss,                      struct sdp_session_s const **return_sdp,                      char const **return_sdp_str,                      isize_t *return_len);@endcode@par Functions for executing Offer/Answer negotiation steps:@codeint soa_init_offer_answer(soa_session_t *ss);int soa_generate_offer(soa_session_t *, int always, soa_callback_f *);int soa_generate_answer(soa_session_t *, soa_callback_f *);int soa_process_answer(soa_session_t *, soa_callback_f *);int soa_process_reject(soa_session_t *, soa_callback_f *);int soa_is_complete(soa_session_t const *ss);@endcode@par Functions for signaling events of session signaling:@codeint soa_activate(soa_session_t *, char const *option);int soa_deactivate(soa_session_t *, char const *option);void soa_terminate(soa_session_t *, char const *option);@endcodeThese functions are used to activate actions taken by @soa, for instance,a COMEDIA connection is established with soa_activate().@par Functions for Checking Activated Media:@codeint soa_is_audio_active(soa_session_t const *ss);int soa_is_video_active(soa_session_t const *ss);int soa_is_remote_audio_active(soa_session_t const *ss);int soa_is_remote_video_active(soa_session_t const *ss);@endcode*/