SIP - The Offer/Answer Model

The use of SDP with SIP is given in the SDP offer answer RFC 3264. The default message body type in SIP is application/sdp.

  • The calling party lists the media capabilities that they are willing to receive in SDP, usually in either an INVITE or in an ACK.

  • The called party lists their media capabilities in the 200 OK response to the INVITE.

A typical SIP use of SDP includes the following fields: version, origin, subject, time, connection, and one or more media and attribute.

  • The subject and time fields are not used by SIP but are included for compatibility.

  • In the SDP standard, the subject field is a required field and must contain at least one character, suggested to be s=- if there is no subject.

  • The time field is usually set to t = 00. SIP uses the connection, media, and attribute fields to set up sessions between UAs.

  • The origin field has limited use with SIP.

  • The session-id is usually kept constant throughout a SIP session.

  • The version is incremented each time the SDP is changed. If the SDP being sent is unchanged from that sent previously, the version is kept the same.

  • As the type of media session and codec to be used are part of the connection negotiation, SIP can use SDP to specify multiple alternative media types and to selectively accept or decline those media types.

The offer/answer specification, RFC 3264, recommends that an attribute containing a = rtpmap: be used for each media field. A media stream is declined by setting the port number to zero for the corresponding media field in the SDP response.

Example

In the following example, the caller Tesla wants to set up an audio and video call with two possible audio codecs and a video codec in the SDP carried in the initial INVITE −

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

The codecs are referenced by the RTP/AVP profile numbers 97, 98.

The called party Marry answers the call, chooses the second codec for the first media field, and declines the second media field, only wanting AMR session.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

If this audio-only call is not acceptable, then Tom would send an ACK then a BYE to cancel the call. Otherwise, the audio session would be established and RTP packets exchanged.

As this example illustrates, unless the number and order of media fields is maintained, the calling party would not know for certain which media sessions were being accepted and declined by the called party.

The offer/answer rules are summarized in the following sections.

Rules for Generating an Offer

An SDP offer must include all required SDP fields (this includes v=, o=, s=, c=,and t=). These are mandatory fields in SDP.

It usually includes a media field (m=) but it does not have to. The media lines contain all codecs listed in preference order. The only exception to this is if the endpoint supports a huge number of codecs, the most likely to be accepted or most preferred should be listed. Different media types include audio, video, text, MSRP, BFCP, and so forth.

Rules for Generating an Answer

An SDP answer to an offer must be constructed according to the following rules −

  • The answer must have the same number of m= lines in the same order as the answer.

  • Individual media streams can be declined by setting the port number to 0.

  • Streams are accepted by sending a nonzero port number.

  • The listed payloads for each media type must be a subset of the payloads listed in the offer.

  • For dynamic payloads, the same dynamic payload number does not need to be used in each direction. Usually, only a single payload is selected.

Rules for Modifying a Session

Either party can initiate another offer/answer exchange to modify a session. When a session is modified, the following rules must be followed −

  • The origin (o=) line version number must either be the same as the last one sent, which indicates that this SDP is identical to the previous exchange, or it may be incremented by one, which indicates new SDP that must be parsed.

  • The offer must include all existing media lines and they must be sent in the same order.

  • Additional media streams can be added to the end of the m= line list.

  • An existing media stream can be deleted by setting the port number to 0. This media line must remain in the SDP and all future offer/answer exchanges for this session.

Call Hold

One party in a call can temporarily place the other on hold. This is done by sending an INVITE with an identical SDP to that of the original INVITE but with a = sendonly attribute present.

The call is made active again by sending another INVITE with the a = sendrecv attribute present. The following illustration shows the call flow of a call hold.

Call Hold
Advertisements