The Sofia SIP soa module consists of an asynchronous SDP Offer/Answer engine library. The interface to library is defined in <sofia-sip/soa.h>.
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 RFC 3264.
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 basic capabilities provided by Offer/Answer mechanism include
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.
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.
Using SDP Offer/Answer with SIP is specified in RFC 3261, RFC 3262 (100rel and PRACK), and RFC 3311 (UPDATE).
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):
Note that due to limitations in space
set_params set_remote gen_offer gen_answer proc_answer This is the "basic" outbound call model.
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 | | | |
| | | |
This is the "basic" inbound call model.
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 | | | |
| | | |
The 3rd-party call model just reverses the O/A roles of callee and caller.
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 | | | |
| | | |
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.
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 | | | | | | | |
The mirror of the previous scenario:
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).
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.
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 | | | | | | | |
The mirror of the previous scenario:
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.