/**@MODULEPAGE "soa" - SDP Offer/Answer Engine Module@section soa_meta Module InformationThe Sofia SIP @b soa module consists of an asynchronous SDP Offer/Answer enginelibrary. The interface to library is defined in <sofia-sip/soa.h>.@CONTACT Pekka Pessi <Pekka.Pessi@nokia.com>@STATUS @SofiaSIP Core library@LICENSE LGPL@section soa_oveview Using soa engineSIP uses SDP and a negotiation procedure known as "SDPOffer-Answer Model" to establish the multimedia sessions. TheSDP Offer-Answer negotiation is specified in <a href="http://ietf.org/rfc/rfc3264.txt">RFC 3264</a>.The soa engine is implemented in object-oriented manner. The default soaobject just implements the basic SDP negotiation and basic SIP call model. Amore complex soa object implementation can manipulate the call model andinitiate actions on behalf of application.@section soa_model SDP Offer/Answer ModelThe 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 toit 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 streamsNote that the capabilites indicate what the party generating theSDP is prepared to receive. They can send anything the other endaccepts.There may be other things, like encryption keys included in thesession description.The advanced capabilities are required by more complicated negotiationinvolving two or more offer-answer rounds. For instance, an extension knownas session <i>preconditions</i> is defined<a href="http://ietf.org/rfc/rfc3312.txt">RFC 3312</a>.Another example of two-phase negotiation is presented in RFC3264 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 offerwith your INVITE, and act on SDP answer in 200 OK?Our design goal is to allow application to follow the simple callmodel, regardless of the underlying complications - earlysessions, preconditions, session timers, 3rd party call control. In other words, we would like a have a simple "cooked" interfacetoward naive applications even if the underlying call follows thebyzantine call model chosen by 3GPP.@section soa_with_sip Using SDP Offer/Answer with SIPUsing 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 UPDATEPRACK may only be sent when an unacknowledged 100rel (reliable 1XXseries response) is received. UPDATE may be sent during early orestablished dialog. Only one INVITE request may be pending within a dialog. Only onenon-INVITE request may be pending within a dialog (in onedirection): it is not possible to send UPDATE if no final responsehas been received to PRACK.If there is already an offer/answer exchange in progress, no offerMUST be sent. Offer/answer exchange is in progress if offer hasbeen sent but no answer has been received, or if an offer has beenreceived but no answer has been generated.The rules for sending answer:- when offer is received with INVITE  - answer MAY be sent with next end-to-end 1XX or 2XX response  - answer MUST be sent in a reliable response (100rel or 2XX)- 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 UPDATEOffer or answer in PRACK MUST be processed even if we have alreadysent 2XX to INVITE.The rules for receiving answer:- if offer was sent in INVITE, first session description in any  non-error response to INVITE is treated as the answer- 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 answerRules 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 ignoredThe re-INVITEs and UPDATEs are sent for two different purposes:updating or modifying SIP state, or updating or modifying theassociated session. Session timer extension (not yet an rfc) is anexample of the first. Putting a call on hold, or adding video toaudio-only call is an example of the second. So, upon receivingre-INVITE, there might be quite different things happening. Theapplication can just return a 200 OK with previous SDP, sometimesit must indicate call being on hold and sometimes ask user forpermission (for adding video).Rules for resolving glare (both endpoints trying to send offer at the sametime):- if a offer is received while UAS has generated an offer,   it must be rejected (with SIP 491 response).@section soa_use_cases SOA and SDP Offer/Answer ScenariosNote 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- 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 - soa_process_answer() is referred as @c proc_answer @subsection soa_uc_basic_out Basic Call OutThis is the "basic" outbound call model.<pre>       APPL	       NUA	       SOA		      REMOTE	|		|		|			| 0      |		|		|			| 1	|----INVITE---->|		|			| 2	|		|--set_params-->|			| 3      |		|---gen_offer-->|			| 4	|		|		|			| 5	|		|-------------------INVITE(sdp offer)-->| 6      |		|		|			| 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	|		|		|			|22	|		|		|			|        |		|		|			|</pre>@subsection soa_uc_basic_in Basic Call InThis is the "basic" inbound call model.<pre>       APPL	       NUA	       SOA		      REMOTE	|		|		|			| 0      |		|		|			| 1	|		|<------------------INVITE(sdp offer)---| 2      |		|		|			| 3	|		|--set_remote-->|			| 4      |		|		|			| 5	|<---INVITE-----|		|			| 6      |		|		|			| 7      |		|		|			| 8	|- - -180- - - >|		|			| 9	|		|- - - - - - - - - - 180 Ringing - - - >|10      |		|		|			|11      |		|		|			|12	|-----200------>|		|			|13	|		|--set_params-->|			|14      |		|		|			|15	|		|--gen_answer-->|			|16	|		|               |			|17	|<----active----|		|			|18	|		|----activate-->|			|19	|		|--------------------200 (sdp answer)-->|20	|		|		|			|21	|		|		|	 		|22	|		|<------------------------ACK-----------|23	|<-----ACK------|		|			|24	|		|		|			|	|		|		|			|</pre>@subsection soa_uc_basic_3p 3rd Party Call In 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---->|   		|			| 8      |		|--set_params-->|			| 9      |		| 		|			|10      |		|--gen_offer--->|			|11	|		|		|			|12      |		|		|			|13      |		|----------------------200 (off) ------>|14	|		|		|			|15	|		|		|	 		|16	|     		|<---------------------ACK (ans)--------|17      |		|--set_remote-->|			|18	|		|--proc_answer->|			|19	|<----ACK-------|		|			|20	|<----active----|		|			|21	|		|----activate-->|			|22      |		|		|			|        |		|		|			|</pre>@subsection soa_uc_early_out Callout with Early MediaIt is possible to establish media session before call is completed. In thiscase, the 180 Ringing contains the SDP answer. A copy of SDP answer isincluded in the 200 OK response, too, because the 180 Ringing is notacknowledged and it may be lost.This is preferred to the basic call model above, as the endpoints has moretime to establish the media session.<pre> t     APPL	       NUA	       SOA		      REMOTE	|		|		|			| 0      |		|		|			| 1	|----INVITE---->|		|			| 2      |		|--set_params-->|			| 3	|		|               |			| 4      |		|--gen_offer--->|			| 5	|		|               |			| 6      |		|		|			| 7      |		|-------------------INVITE(sdp offer)-->| 8	|		|		|			| 9	|		|		|			|10      |		|		|			|11      |		|<-------------------180(sdp answer)----|12      |		|--set_remote-->|			|13	|<-----180------|--proc_answer->|	    		|14	|   		|		|			|15      |		|		|			|16	|		|		|			|17	|		|<-----------------200(copy of answer)--|18	|	(copy is ignored)	|			|19	|		|		|			|20	|<-----200------|		|			|21	|		|----activate-->|			|22	|<----active----|		|			|23	|		|-------------------------ACK---------->|24	|		|		|			|	|		|		|			|</pre>@subsection soa_uc_early_in Call In Establishing Early MediaThe mirror of the previous scenario:<pre> t     APPL	       NUA	       SOA		      REMOTE	|		|		|			| 0      |		|		|			| 1	|		|<------------------INVITE(sdp offer)---| 2      |		|--set_remote-->|			| 3	|<---INVITE-----|		|			| 4      |		|		|			| 5      |   		|		|			| 6	|---180 Ring--->|   		|			| 7      |		|--set_params-->|			| 8      |		|--gen_offer--->| 			| 9      |		|	     (Note 1)			|10      |		|		|			|11      |		|-------------------180 (sdp answer)--->|12	|		|		|			|13	|		|		|			|14	|		|		|			|15	|----200 OK---->|		|			|16	|		|--set_params-->|			|17	|		|		|			|18	|		|		|			|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 isthat callee sends a ringing tone towards caller and discards any media sentby caller until the call is accepted (200 OK is sent towards caller).@subsection soa_uc_100rel_out Call Out with PRACKHere is second alternative establishing media session before call iscompleted. In this case, the 180 Ringing contains the SDP answer. The 180Ringing is now sent reliably. In other words, it is acknowledged by a PRACKrequest.<pre> t     APPL	       NUA	       SOA		      REMOTE	|		|		|			| 0      |		|		|			| 1	|----INVITE---->|		|			| 2      |		|--set_params-->|			| 3	|		|               |			| 4      |		|--gen_offer--->|			| 5	|		|		|			| 6      |		|		|			| 7      |		|-------------------INVITE(sdp offer)-->| 8	|		|		|			| 9	|		|		|			|10      |		|<-------------------183(sdp answer)----|11      |		|--set_remote-->|			|12      |		|--proc_answer->|			|13	|<-----183------|		|	    		|14	|   		|		|			|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>@subsection soa_uc_100rel_in Call In with PRACKThe 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 thatcallee sends a ringing tone towards caller and discards any media sent bycallee 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 themedia session has been successfully established.*//**@page soa_sdp_oa_use_cases Use Cases for SIP and SDP Offer/AnswerThis page contains a list of use cases or call scenarios for SIP and SDP