RFC 3264 (rfc3264) - Page 2 of 25
An Offer/Answer Model with Session Description Protocol (SDP)
Alternative Format: Original Text Document
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 set supported by each participant. As a result, even though SDP has the expressiveness to describe unicast sessions, it is missing the semantics and operational details of how it is actually done. In this document, we remedy that by defining a simple offer/answer model based on SDP. In this model, one participant in the session generates an SDP message that constitutes the offer - the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media. The offer is Rosenberg & Schulzrinne Standards Track
