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 [Page 2]
RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
conveyed to the other participant, called the answerer. The answerer
generates an answer, which is an SDP message that responds to the
offer provided by the offerer. The answer has a matching media
stream for each stream in the offer, indicating whether the stream is
accepted or not, along with the codecs that will be used and the IP
addresses and ports that the answerer wants to use to receive media.
It is also possible for a multicast session to work similar to a
unicast one; its parameters are negotiated between a pair of users as
in the unicast case, but both sides send packets to the same
multicast address, rather than unicast ones. This document also
discusses the application of the offer/answer model to multicast
streams.
We also define guidelines for how the offer/answer model is used to
update a session after an initial offer/answer exchange.
The means by which the offers and answers are conveyed are outside
the scope of this document. The offer/answer model defined here is
the mandatory baseline mechanism used by the Session Initiation
Protocol (SIP) [7].
2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant implementations.
/
3 Definitions
The following terms are used throughout this document:
Agent: An agent is the protocol implementation involved in the
offer/answer exchange. There are two agents involved in an
offer/answer exchange.
Answer: An SDP message sent by an answerer in response to an offer
received from an offerer.
Answerer: An agent which receives a session description from
another agent describing aspects of desired media
communication, and then responds to that with its own session
description.
Rosenberg & Schulzrinne Standards Track [Page 3]
RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
Media Stream: From RTSP [8], a media stream is a single media
instance, e.g., an audio stream or a video stream as well as a
single whiteboard or shared application group. In SDP, a media
stream is described by an "m=" line and its associated
attributes.
Offer: An SDP message sent by an offerer.
Offerer: An agent which generates a session description in order
to create or modify a session.
4 Protocol Operation
The offer/answer exchange assumes the existence of a higher layer
protocol (such as SIP) which is capable of exchanging SDP for the
purposes of session establishment between agents.
Protocol operation begins when one agent sends an initial offer to
another agent. An offer is initial if it is outside of any context
that may have already been established through the higher layer
protocol. It is assumed that the higher layer protocol provides
maintenance of some kind of context which allows the various SDP
exchanges to be associated together.
The agent receiving the offer MAY generate an answer, or it MAY
reject the offer. The means for rejecting an offer are dependent on
the higher layer protocol. The offer/answer exchange is atomic; if
the answer is rejected, the session reverts to the state prior to the
offer (which may be absence of a session).
At any time, either agent MAY generate a new offer that updates the
session. However, it MUST NOT generate a new offer if it has
received an offer which it has not yet answered or rejected.
Furthermore, it MUST NOT generate a new offer if it has generated a
prior offer for which it has not yet received an answer or a
rejection. If an agent receives an offer after having sent one, but
before receiving an answer to it, this is considered a "glare"
condition.
The term glare was originally used in circuit switched
telecommunications networks to describe the condition where two
switches both attempt to seize the same available circuit on the
same trunk at the same time. Here, it means both agents have
attempted to send an updated offer at the same time.
RFC 3264 一个访问/回答的模型 会话描述协议 六月 2002 [Page 2]
一个访问/回答的模型，会话描述协议 被发送给了一个会话参与者，这个参与者将产生一个对与SDP消息的应答，应答中将产生对于访问者提供的每一个媒体流匹配媒体流，预示着某个媒体流的被接受与否，随着回答的代码一同发出的还有接受者将用与接受未来到来的媒体流的IP地址信息与端口号.
一个多播的工作机制和单播是想类似的，如同单播中，多播的参与者的会话协商是在一群参与者中的
但是所有参与者都是发送数据包到一个相同多播地址，这个文档就是讨论了 这种询问/响应 模型在多播中的应用.我们也定义了 这种询问/响应 模型如何去更新一个会话在初始建立了一个会话后。
至于 访问者和应答者传送信息的方法，建立会话的过程，不在本文档的讨论范围之内，这种询问/响应会话的建立，基本是基与SIP协议来进行的.
术语
在这个文档中，关键字"MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","OPTIONAL"在RFC2119[2]中有相关解释论述
定义
下面术语的使用将贯穿整个文献
代理：一个代理是包含在询问/响应交换过程中的协议执行者，在一次询问/响应交换过程，一般都是有两个代理
响应：接受到一个SDP消息后，响应者对这个SDP消息的回答
响应者：接受到另外一个代理发出的对与媒体信息流的SDP消息后，能自己去响应对应的SDP消息
RFC 3264 一个访问/回答的模型 会话描述协议 六月 2002 [Page 3]
媒体流：一个媒体流是这样一个媒体实例，如同简单白板或共享应用群的一个视频流或者音频流，在SDP协议中，一个媒体流被"m="行和其相关的属性所描述
访问命令：一个访问者发出的SDP消息
访问者：创建或更改一个会话，按顺序产生会话描述的代理
协议操作
这样的请求/响应交互 是假设借助与SIP协议，SIP协议有能力在代理间完成SDP消息的交互
协议操作开始与当一个代理发出一个初始邀请给另一个代理，一个请求如果没有存在与任何交互的背景中将被初始化，并可能通过高层协议创建
我们也假设高层协议提供了这样一种机制，这样的机制可以使得不同的SDP消息交互被相互联系
一个代理收到一个请求可能产生响应或者直接拒绝，拒绝时候采用的方法取决与高层协议，这种请求/响应是自动的，如果
响应是拒绝，会话将优先回到访问者的当前状态
在任何时间，任何一个代理都可以产生一个新的请求去更新当前会话，但是一个代理不能在收到一个请求，在他还没有做出响应或者拒绝前再发出一个请求
甚至，在他发出一个请求但还没有收到响应或者拒绝的时候再发出一个请求，如果一个代理在发出一个请求后，收到一个请求，但是还没有收到此前发出那个请求的响应，这时候
这个代理所存在的状态，我们称之为 “眩目”
这个名称起源与电路交换，在电话网络中描述这样一种状况，2个交换机同时在同一干线上争夺一条电路的使用权
在这里，这个名称用来描述2个代理想在同一时间去更新当前的会话
发表于 2009-2-26 18:27:01
