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.
The offerer indicates its capabilities in the offer:
The answerer indicates which parts of the offer are acceptable to it in the answer:
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 preconditions is defined RFC 3312. Another example of two-phase negotiation is presented in RFC 3264 section 10.2, showing how a single codec can be selected.
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.
There is a separate page listing scenarios.
The rules for sending offers:
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.
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.
The rules for sending answer:
Offer or answer in PRACK MUST be processed even if we have already sent 2XX to INVITE.
The rules for receiving answer:
Rules for situations when endpoint MUST ignore the SDP:
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).
Rules for resolving glare (both endpoints trying to send offer at the same time):
set_params
set_remote
gen_offer
gen_answer
proc_answer
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 | | | | | | | |
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 | | | | | | | |
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 | | | | | | | |
This is preferred to the basic call model above, as the endpoints has more time to establish the media session.
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 | | | | | | | |
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 | | | | | | | |Note 1: the user expectation (set by ordinary telephone) here is that callee sends a ringing tone towards caller and discards any media sent by caller until the call is accepted (200 OK is sent towards caller).
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 | | | | | | | |
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 | | | | | | | |
Note 1: 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.