sdp_offer_answer_examples.txt

This gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include

Network Working Group                                        A. Johnston
Request for Comments: 4317                             Tello Corporation
Category: Informational                                        R. Sparks
                                                        Estacado Systems
                                                           December 2005


                   Session Description Protocol (SDP)
                         Offer/Answer Examples

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document gives examples of Session Description Protocol (SDP)
   offer/answer exchanges.  Examples include codec negotiation and
   selection, hold and resume, and addition and deletion of media
   streams.  The examples show multiple media types, bidirectional,
   unidirectional, inactive streams, and dynamic payload types.  Common
   Third Party Call Control (3pcc) examples are also given.























Johnston & Sparks            Informational                      [Page 1]

RFC 4317               SDP Offer/Answer Examples           December 2005


Table of Contents

   1. Overview ........................................................3
   2. Codec Negotiation and Selection .................................3
      2.1. Audio and Video 1 ..........................................3
      2.2. Audio and Video 2 ..........................................4
      2.3. Audio and Video 3 ..........................................5
      2.4. Two Audio Streams ..........................................6
      2.5. Audio and Video 4 ..........................................7
      2.6. Audio Only 1 ...............................................8
      2.7. Audio and Video 5 ..........................................9
      2.8. Audio and Video 6 .........................................10
   3. Hold and Resume Scenarios ......................................12
      3.1. Hold and Unhold 1 .........................................12
      3.2. Hold with Two Streams .....................................13
   4. Addition and Deletion of Media Streams .........................15
      4.1. Second Audio Stream Added .................................15
      4.2. Audio, then Video Added ...................................16
      4.3. Audio and Video, Then Video Deleted .......................17
   5. Third Party Call Control (3pcc) ................................19
      5.1. No Media, Then Audio Added ................................19
      5.2. Hold and Unhold 2 .........................................20
      5.3. Hold and Unhold 3 .........................................21
   6. Security Considerations ........................................22
   7. Informative References .........................................22


























Johnston & Sparks            Informational                      [Page 2]

RFC 4317               SDP Offer/Answer Examples           December 2005


1.  Overview

   This document describes offer/answer examples of Session Description
   Protocol (SDP) based on RFC 3264 [1].  The SDP in these examples is
   defined by RFC 2327 [2].  The offers and answers are assumed to be
   transported using a protocol such as Session Initiation Protocol
   (SIP) [3].

   Examples include codec negotiation and selection, hold and resume,
   and addition and deletion of media streams.  The examples show
   multiple media types, bidirectional, unidirectional, inactive
   streams, and dynamic payload types.  Common Third Party Call Control
   (3pcc) [5] examples are also given.

   The following sections contain examples in which two parties, Alice
   and Bob, exchange SDP offers, answers, and, in some cases, additional
   offers and answers.  Note that the subject line (s=) contains a
   single space character.

2.  Codec Negotiation and Selection

2.1.  Audio and Video 1

   This common scenario shows a video and audio session in which
   multiple codecs are offered but only one is accepted.  As a result of
   the exchange shown below, Alice and Bob may send only PCMU audio and
   MPV video.  Note: Dynamic payload type 97 is used for iLBC codec [6].

    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 8 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31 32
      a=rtpmap:31 H261/90000
      a=rtpmap:32 MPV/90000









Johnston & Sparks            Informational                      [Page 3]

RFC 4317               SDP Offer/Answer Examples           December 2005


    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49174 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 49170 RTP/AVP 32
      a=rtpmap:32 MPV/90000

2.2.  Audio and Video 2

   Alice can support PCMU, PCMA, and iLBC codecs, but not more than one
   at the same time.  Alice offers all three to maximize chances of a
   successful exchange, and Bob accepts two of them.  An audio-only
   session is established in the initial exchange between Alice and Bob,
   using either PCMU or PCMA codecs (payload type in RTP packet tells
   which is being used).  Since Alice only supports one audio codec at a
   time, a second offer is made with just that one codec, to limit the
   codec choice to just one.

   Note: the version number is incremented in both SDP messages in the
   second exchange.  After this exchange, only the PCMU codec may be
   used for media session between Alice and Bob.

   Note: The declined video stream still present in the second exchange
   of SDP with ports set to zero.

    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 8 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31 32
      a=rtpmap:31 H261/90000
      a=rtpmap:32 MPV/90000







Johnston & Sparks            Informational                      [Page 4]

RFC 4317               SDP Offer/Answer Examples           December 2005


    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49172 RTP/AVP 0 8
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      m=video 0 RTP/AVP 31
      a=rtpmap:31 H261/90000

    [Second-Offer]

      v=0
      o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 51372 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 0 RTP/AVP 31
      a=rtpmap:31 H261/90000

    [Second-Answer]

      v=0
      o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49172 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 0 RTP/AVP 31
      a=rtpmap:31 H261/90000

2.3.  Audio and Video 3

   Alice offers three audio and two video codecs, while Bob accepts with
   a single audio and video codec.  As a result of this exchange, Bob
   and Alice use iLBC for audio and H261 for video.

   Note: change of dynamic payload type from 97 to 99 between the offer
   and the answer is OK since the same codec is referenced.






Johnston & Sparks            Informational                      [Page 5]

RFC 4317               SDP Offer/Answer Examples           December 2005


    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 8 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31 32
      a=rtpmap:31 H261/90000
      a=rtpmap:32 MPV/90000

    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49172 RTP/AVP 99
      a=rtpmap:99 iLBC/8000
      m=video 51374 RTP/AVP 31
      a=rtpmap:31 H261/90000

2.4.  Two Audio Streams

   In this example, Alice wishes to establish separate audio streams,
   one for normal audio and the other for telephone-events.  Alice
   offers two separate streams, one audio with two codecs and the other
   with RFC 2833 [4] tones (for DTMF).  Bob accepts both audio streams
   choosing the iLBC codec and telephone-events.

















Johnston & Sparks            Informational                      [Page 6]

RFC 4317               SDP Offer/Answer Examples           December 2005


    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 0 97
      a=rtpmap:0 PCMU/8000
      a=rtpmap:97 iLBC/8000
      m=audio 49172 RTP/AVP 98
      a=rtpmap:98 telephone-event/8000
      a=sendonly

    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49172 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=audio 49174 RTP/AVP 98
      a=rtpmap:98 telephone-event/8000
      a=recvonly

2.5.  Audio and Video 4

   Alice and Bob establish an audio and video session with a single
   audio and video codec.  In a second exchange, Bob changes his address
   for media and Alice accepts with the same SDP as the initial exchange
   (and as a result does not increment the version number).

    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31
      a=rtpmap:31 H261/90000






Johnston & Sparks            Informational                      [Page 7]

RFC 4317               SDP Offer/Answer Examples           December 2005


    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0
      m=audio 49174 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=video 49170 RTP/AVP 31
      a=rtpmap:31 H261/90000

    [Second-Offer]

      v=0
      o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 newhost.biloxi.example.com
      t=0 0
      m=audio 49178 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=video 49188 RTP/AVP 31
      a=rtpmap:31 H261/90000

    [Second-Answer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0
      m=audio 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31
      a=rtpmap:31 H261/90000

2.6.  Audio Only 1

   Alice wishes to establish an audio session with Bob using either PCMU
   codec or iLBC codec with RFC2833 tones, but not both at the same
   time.  The offer contains these two media streams.  Bob declines the
   first one and accepts the second one.  If both media streams had been
   accepted, Alice would have sent a second declining one of the
   streams, as shown in Section 4.3.







Johnston & Sparks            Informational                      [Page 8]

RFC 4317               SDP Offer/Answer Examples           December 2005