Use Cases for SIP and SDP Offer/Answer
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:
- calling to existing PSTN networks (early session)
- doing resource reservations
- calling to 3G IMS
- call hunting
- having external party setting up your call, etc.
Case #1: Basic Call
This is the basic SIP call model with the most simple offer-answer exchange.
A B
| |
|----INVITE (offer)---->|
| |
| |
|< - - 180 Ringing - - -|
| |
| |
|<----200 (answer)------|
|----------ACK--------->|
| |
| | Case #2: Early Media
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 "thesubscriber 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.
Case #3: Early Dialog, Early Media
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--------->|
| |
| | Case #4: UPDATE with Offer
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--------->|
| |
| | Case #5: 2nd Offer in PRACK
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--------->|
| |
| | Case #6: Callee Making 2nd Offer
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--------->|
| |
| | Case #7: 3GPP Call Model
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--------->|
| |
| | Case #8: Forking
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).
Case #9: 3rd Party Call Control
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--------->|
| | | Case #10: Upgrade Session with Re-INVITE
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--------->|
| |
| | Case #10: Upgrade Session with Re-INVITE
A B
| |
|----INVITE (offer1)--->|
| |
| |
|< - - 180 Ringing - - -|
| |
| |
|<----200 (answer2)-----|
|----------ACK--------->|
| |
| |
| |
| |
|----INVITE (offer2)--->|
| |
|<---------488----------|
|----------ACK--------->|
| |
| |