C114门户论坛百科APPEN| 举报 切换到宽版

亚星游戏官网

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索

军衔等级:

亚星游戏官网-yaxin222  三级通信军士

注册:2008-12-8
发表于 2009-2-26 18:27:01 |显示全部楼层
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 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个代理想在同一时间去更新当前的会话

举报本楼

您需要登录后才可以回帖 登录 | 注册 |

手机版|C114 ( 沪ICP备12002291号-1 )|联系大家 |网站地图  

GMT+8, 2024-11-27 07:28 , Processed in 0.266620 second(s), 15 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部
XML 地图 | Sitemap 地图