Loading...
Searching...
No Matches
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 "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.

# 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

The session upgraded is rejected.

        A               B
        |           |
        |----INVITE (offer1)--->|
        |           |
        |           |
        |< - - 180 Ringing - - -|
        |           |
        |           |
        |<----200 (answer2)-----|
        |----------ACK--------->|
        |           |
        |           |
        |           |
        |           |
        |----INVITE (offer2)--->|
        |           |
        |<---------488----------|
        |----------ACK--------->|
        |           |
        |           |

Sofia-SIP 1.12.11devel - Copyright (C) 2006 Nokia Corporation. All rights reserved. Licensed under the terms of the GNU Lesser General Public License.