Loading...
Searching...
No Matches
Sofia SIP User Agent Library - "soa" - SDP Offer/Answer Engine Module

# Module Information

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>.

Contact:\n Pekka Pessi <Pekka.Pessi@nokia-email.address.hidden>

Status:\n Sofia SIP Core library

License:\n LGPL

# Using soa engine

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.

# SDP Offer/Answer Model

The basic capabilities provided by Offer/Answer mechanism include

1. generating SDP offer (section 5)
2. processing SDP offer, generating SDP answer (section 6)
3. processing SDP answer (section 7)
4. modifying session (section 8)
5. indicating capabilities (section 9)

The offerer indicates its capabilities in the offer:

- the media streams it wants to establish
- transport addresses it uses to receive by media streams (IP addresses, port numbers, transport protocols)
- the codecs used by particular streams
- codec parameters (for instance, codec profile used by H.263)

The answerer indicates which parts of the offer are acceptable to it in the answer:

- the media streams it agrees to establish
- transport addresses answerer uses to receive by media streams
- the codecs and codec parameters used by particular streams

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.

# SOA Design

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

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:

- offer may be sent in INVITE
- if there was no offer in INVITE, offer MUST be sent in first reliable response to INVITE
- offer may be sent in 100rel (reliable 1XX series response)
- offer may be sent in PRACK
- offer may be sent in UPDATE

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:

- when offer is received with INVITE
  - answer MAY be sent with next end-to-end 1XX or 2XX response
  - answer MUST be sent in a reliable response (100rel or 2XX)
- when offer is received in 2XX response
  - answer MUST be sent in ACK
- when offer is received with 100rel response
  - answer MUST be sent with PRACK
- when offer is received with PRACK or UPDATE
  - answer MUST be sent with 2XX response to PRACK or UPDATE

Offer or answer in PRACK MUST be processed even if we have already sent 2XX to INVITE.

The rules for receiving answer:

- if offer was sent in INVITE, first session description in any non-error response to INVITE is treated as the answer
- if offer was sent in 2XX response, session description in ACK is answer
- if offer was sent in 100rel response, session description in PRACK is answer
- if offer was sent in PRACK or UPDATE, session description in 2XX response is answer

Rules for situations when endpoint MUST ignore the SDP:

- If offer was sent in INVITE, only the first session description in any non-error (1XX or 2XX) response to INVITE is processed, rest are ignored
- If no offer was sent in 2XX response to INVITE, SDP in ACK is ignored
- If no offer was sent in PRACK, SDP in response to it is ignored
- If no offer was sent in UPDATE, SDP in response to it is ignored

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):

- if a offer is received while UAS has generated an offer, it must be rejected (with SIP 491 response).

# SOA and SDP Offer/Answer Scenarios

Note that due to limitations in space

- soa_set_params() is referred as `set_params`
- soa_set_remote_sdp() is referred as `set_remote`
- soa_generate_offer() followed by soa_get_session_sdp() is referred as `gen_offer`
- soa_generate_answer() followed by soa_get_session_sdp() is referred as `gen_answer`
- soa_process_answer() is referred as `proc_answer`

## Basic Call Out

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  |       |       |           |
            |       |       |           |

## Basic Call In

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  |       |       |           |
        |       |       |           |

## 3rd Party Call In

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      |       |       |           |
            |       |       |           |

## Callout with Early Media

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  |       |       |           |
        |       |       |           |

## Call In Establishing Early Media

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).

## Call Out with PRACK

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  |       |       |           |
        |       |       |           |

## Call In with PRACK

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.

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