sdp_offer_answer_examples.txt

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

    [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
      a=rtpmap:0 PCMU/8000

    [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 49170 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 49172 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 49168 RTP/AVP 31
      a=rtpmap:31 H261/90000

4.3.  Audio and Video, Then Video Deleted

   Alice and Bob establish an audio and video session.  In a second
   exchange, Bob deletes the video session, resulting in an audio-only
   session.











Johnston & Sparks            Informational                     [Page 17]

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 97
      a=rtpmap:97 iLBC/8000
      m=video 51372 RTP/AVP 31
      a=rtpmap:31 H261/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 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 host.biloxi.example.com
      t=0 0
      m=audio 49174 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=video 0 RTP/AVP 31
      a=rtpmap:31 H261/90000

    [Second-Answer]

      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 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000
      m=video 0 RTP/AVP 31
      a=rtpmap:31 H261/90000




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


5.  Third Party Call Control (3pcc)

   This section shows examples common in Third Party Call Control (3pcc)
   flows [5].  Call hold and resume flows are also common in 3pcc.

5.1.  No Media, Then Audio Added

   The first offer from Alice contains no media lines, so Bob accepts
   with no media lines.  In the second exchange, Alice adds an audio
   stream that Bob accepts.

    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 host.atlanta.example.com
      t=0 0

    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 host.biloxi.example.com
      t=0 0

    [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 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000

    [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 97
      a=rtpmap:97 iLBC/8000





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


5.2.  Hold and Unhold 2

   The first offer from Alice contains the connection address 0.0.0.0
   and a random port number, which means that Bob can not send media to
   Alice (the media stream is "black holed" or "bh").  Bob accepts with
   normal SDP.  In the second exchange, Alice changes the connection
   address, Bob accepts, and a media session is established.

    [Offer]

      v=0
      o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
      s=
      c=IN IP4 0.0.0.0
      t=0 0
      m=audio 23442 RTP/AVP 97
      a=rtpmap:97 iLBC/8000

    [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 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000

    [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 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000

    [Second-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 49170 RTP/AVP 97
      a=rtpmap:97 iLBC/8000




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


5.3.  Hold and Unhold 3

   The first offer from Alice contains an audio stream, but the answer
   from Bob contains the connection address 0.0.0.0 and a random port
   number, which means that Alice can not send media to Bob (the media
   stream is "black holed" or "bh").  In the second exchange, Bob
   changes the connection address, Alice accepts, and a media session is
   established.

    [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

    [Answer]

      v=0
      o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
      s=
      c=IN IP4 0.0.0.0
      t=0 0
      m=audio 9322 RTP/AVP 97
      a=rtpmap:97 iLBC/8000

    [Second-Offer]

      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 97
      a=rtpmap:97 iLBC/8000

    [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



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


6.  Security Considerations

   SDP offer and answer messages can contain private information about
   addresses and sessions to be established between parties.  If this
   information needs to be kept private, some security mechanism in the
   protocol used to carry the offers and answers must be used.  For SIP,
   this means using TLS transport and/or S/MIME encryption of the SDP
   message body.

   It is important that SDP offer and answer messages be properly
   authenticated and authorized before they are used to establish a
   media session.  Examples of SIP mechanisms include SIP Digest, certs,
   and cryptographically-verified SIP identity.

7.  Informative References

   [1]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [2]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [4]  Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
        Telephony Tones and Telephony Signals", RFC 2833, May 2000.

   [5]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
        "Best Current Practices for Third Party Call Control (3pcc) in
        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
        April 2004.

   [6]  Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP)
        Payload Format for internet Low Bit Rate Codec (iLBC) Speech",
        RFC 3952, December 2004.














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


Authors' Addresses

   Alan Johnston
   Tello Corporation
   999 Baker Way, Suite 250
   San Mateo, CA 94404

   EMail: [e-mail]


   Robert J. Sparks
   Estacado Systems

   EMail: [e-mail]





































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


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Johnston & Sparks            Informational                     [Page 24]