This page contains a list of use cases or call scenarios for SIP and SDP Offer/Answer.
There are a few call scenarios that we expect to see when dealing with more telephone-like side of SIP:
This is the basic SIP call model with the most simple offer-answer exchange.
A B | | |----INVITE (offer)---->| | | | | |< - - 180 Ringing - - -| | | | | |<----200 (answer)------| |----------ACK--------->| | | | |
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...":
A B | | |----INVITE (offer)---->| | | | | |<----180 (answer)------| | | | | |<----200 (answer')-----| |----------ACK--------->| | | | |
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.
This case is a call using 100rel, early dialog and early media. It is used when the session should be established before call alerts.
A B | | |----INVITE (offer)---->| | | |<----183 (answer)------| |--------PRACK--------->| |<-----200/PRACK------->| | | |<---------180----------| |--------PRACK--------->| |<-----200/PRACK------->| | | | | | | |<---------200----------| |----------ACK--------->| | | | |
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":
A B | | |----INVITE (offer)---->| | | | | |<----183 (answer)------| |--------PRACK--------->| |<-----200/PRACK--------| | | | | |----UPDATE (offer2)--->| |<-200/UPDATE (answer2)-| | | |<---------180----------| |--------PRACK--------->| |<-----200/PRACK------->| | | | | |<---------200----------| |----------ACK--------->| | | | |
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":
A B | | |----INVITE (offer)---->| | | |<----183 (answer)------| |-----PRACK(offer2)---->| |<--200/PRACK(answer2)--| | | | | |<---------180----------| |--------PRACK--------->| |<-----200/PRACK------->| | | | | |<---------200----------| |----------ACK--------->| | | | |
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:
A B | | |----INVITE (offer)---->| | | |<----183 (answer)------| |--------PRACK--------->| |<-----200/PRACK------->| | | | | |<---UPDATE (offer2)----| |-200/UPDATE (answer2)->| | | |<---------180----------| |--------PRACK--------->| |<-----200/PRACK------->| | | | | |<---------200----------| |----------ACK--------->| | | | |
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:
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--------->|
| |
| |
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:
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----------------------------------------->| | | | | | | | |
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).
Now something different: 3rd party call model, where "C" establishes the call:
A C B | | | |<-------INVITE---------| | | | | | | | |------200 (offer)----->| | | |----INVITE (offer)---->| | | | | | | | |<-----200 (answer)-----| |<-----ACK (answer)-----| | | | | | |----------ACK--------->| | | |
The session is upgraded: a new media is added to the session.
A B | | |----INVITE (offer1)--->| | | | | |< - - 180 Ringing - - -| | | | | |<----200 (answer2)-----| |----------ACK--------->| | | | | | | | | |----INVITE (offer2)--->| | | |<----200 (answer2)-----| |----------ACK--------->| | | | |
The session upgraded is rejected.
A B | | |----INVITE (offer1)--->| | | | | |< - - 180 Ringing - - -| | | | | |<----200 (answer2)-----| |----------ACK--------->| | | | | | | | | |----INVITE (offer2)--->| | | |<---------488----------| |----------ACK--------->| | | | |