An Offer/Answer Model with Session Description Protocol (SDP)
RFC 3264
Document | Type |
RFC - Proposed Standard
(July 2002; Errata)
Obsoletes RFC 2543
|
|
---|---|---|---|
Authors | Henning Schulzrinne , Jonathan Rosenberg | ||
Last updated | 2020-01-21 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized with errata bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3264 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
IESG note |
RFCs 3261-3265 Responsible: Finished |
||
Send notices to | <jo@acm.org>, <csp@csperkins.org> |
Network Working Group J. Rosenberg Request for Comments: 3264 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. June 2002 An Offer/Answer Model with the Session Description Protocol (SDP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). Table of Contents 1 Introduction ........................................ 2 2 Terminology ......................................... 3 3 Definitions ......................................... 3 4 Protocol Operation .................................. 4 5 Generating the Initial Offer ........................ 5 5.1 Unicast Streams ..................................... 5 5.2 Multicast Streams ................................... 8 6 Generating the Answer ............................... 9 6.1 Unicast Streams ..................................... 9 6.2 Multicast Streams ................................... 12 7 Offerer Processing of the Answer .................... 12 8 Modifying the Session ............................... 13 Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002 8.1 Adding a Media Stream ............................... 13 8.2 Removing a Media Stream ............................. 14 8.3 Modifying a Media Stream ............................ 14 8.3.1 Modifying Address, Port or Transport ................ 14 8.3.2 Changing the Set of Media Formats ................... 15 8.3.3 Changing Media Types ................................ 17 8.3.4 Changing Attributes ................................. 17 8.4 Putting a Unicast Media Stream on Hold .............. 17 9 Indicating Capabilities ............................. 18 10 Example Offer/Answer Exchanges ...................... 19 10.1 Basic Exchange ...................................... 19 10.2 One of N Codec Selection ............................ 21 11 Security Considerations ............................. 23 12 IANA Considerations ................................. 23 13 Acknowledgements .................................... 23 14 Normative References ................................ 23 15 Informative References .............................. 24 16 Authors' Addresses .................................. 24 17 Full Copyright Statement............................. 25 1 Introduction The Session Description Protocol (SDP) [1] was originally conceived as a way to describe multicast sessions carried on the Mbone. The Session Announcement Protocol (SAP) [6] was devised as a multicast mechanism to carry SDP messages. Although the SDP specification allows for unicast operation, it is not complete. Unlike multicast, where there is a global view of the session that is used by all participants, unicast sessions involve two participants, and a complete view of the session requires information from both participants, and agreement on parameters between them. As an example, a multicast session requires conveying a single multicast address for a particular media stream. However, for a unicast session, two addresses are needed - one for each participant. As another example, a multicast session requires an indication of which codecs will be used in the session. However, for unicast, the set of codecs needs to be determined by finding an overlap in the setShow full document text