宜昌市建设工程质量监督站网站,app运营推广策划方案,嵌入式软件开发公司,谷德设计网入口1、引入 在松耦合会议中#xff0c;会话参数完全由会议创建者来确定#xff0c;参与者能做的仅仅是根据这些会话参数来加入会议#xff08;当然也可以选择不加入#xff09;。这种情况下#xff0c;主要要做的就是会话描述#xff0c;在这里SDP本身就足够了。 但是在更为… 1、引入 在松耦合会议中会话参数完全由会议创建者来确定参与者能做的仅仅是根据这些会话参数来加入会议当然也可以选择不加入。这种情况下主要要做的就是会话描述在这里SDP本身就足够了。 但是在更为普遍的两方会话的情况下由于用户终端能力的差异任何一方不能假设对方一定支持某种会话参数所以必须双方协商来最终就会话的参数达成一致。显然SDP能做到准确的描述会话的参数但是它缺少双发如何根据各自提供的会话描述形成最终一致的会话描述的语义及操作上的细节。 IETF RFC3264定义了一个基于SDP的简单的提议/应答模型来实现这一点。 2、提议/应答操作概述 在提议/应答模型中首先会话的一方提议者产生一个 SDP消息来描述它所期望的会话这构成了一个提议offer。提议中主要包括提议者想使用的媒体流和codecs集以及提议者用于接收媒体的IP地址和端口。 提议被传送到另一方收到这个提议后这一方可能会接受也可能会拒绝这个提议。在前一种情况下本方应答者根据收到的提议和自身的能力产生一个SDP消息来描述它所能接受的会话这称为应答answer应答中针对提议中的每个媒体流有一个匹配流指示该媒体流是否被接受同时伴随着要使用的codecs和应答者希望用于接收媒体的 IP 地址和端口。 在提议/应答的操作中需遵守以下原则 在任何时候任何一方都可能产生一个新的提议来更新会话。然而如果它收到了一个提议还没有应答或拒绝则不能产生新的提议。提议/应答交换是不可分的如果应答被拒绝会话恢复到提议前的状态。提议 (和应答) 必须是RFC 2327 中所定义的有效SDP消息。尽管 SDP 规范允许将多个会话描述串接在一起形成一个大的SDP 消息但是在提议/应答模型中使用的SDP消息必须恰好包含一个会话描述。 在提议/应答模型中交换假定存在一个高层协议(比如SIP)它能够完成SDP消息的交换并能维持某种上下文关系将一个提议及其应答和创建和更新同一个会话的多个提议/应答对关联起来。 3、提议/应答交换例子 下面给出一个简单的提议/应答交换的例子。 假设主叫A发送一个提议给被叫B。提议中包含一个双向的音频流和两个双向的视频流分别使用H.261 (净荷类型31) 和MPEG(净荷类型32)。 提议的SDP如下 v0 oalice 2890844526 2890844526 IN IP4 host.anywhere.com s cIN IP4 host.anywhere.com t0 0 maudio 49170 RTP/AVP 0 artpmap:0 PCMU/8000 mvideo 51372 RTP/AVP 31 artpmap:31 H261/90000 mvideo 53000 RTP/AVP 32 artpmap:32 MPV/90000 被叫B不想发送和接收第一个视频流所以返回以下SDP作为应答。注意描述第一个视频流的m行中端口设为0这表示拒绝这个媒体流。 v0 obob 2890844730 2890844730 IN IP4 host.example.com s cIN IP4 host.example.com t0 0 maudio 49920 RTP/AVP 0 artpmap:0 PCMU/8000 mvideo 0 RTP/AVP 31 mvideo 53000 RTP/AVP 32 artpmap:32 MPV/90000 之后的某一时刻B决定改变其接收音频流的端口(从49920 改为65422)同时增加另一个“仅接收”的音频流注意其属性为recvonly使用 RTP 净荷类型 events 。 B提供了以下SDP作为提议 v0 obob 2890844730 2890844731 IN IP4 host.example.com s cIN IP4 host.example.com t0 0 maudio 65422 RTP/AVP 0 artpmap:0 PCMU/8000 mvideo 0 RTP/AVP 31 mvideo 53000 RTP/AVP 32 artpmap:32 MPV/90000 maudio 51434 RTP/AVP 110 artpmap:110telephone-events/8000 arecvonly A接受这个新增的媒体流注意在其属性为sendonly所以产生以下的应答 v0 oalice 2890844526 2890844527 IN IP4 host.anywhere.com s cIN IP4 host.anywhere.com t0 0 maudio 49170 RTP/AVP 0 artpmap:0 PCMU/8000 mvideo 0 RTP/AVP 31 artpmap:31 H261/90000 mvideo 53000 RTP/AVP 32 artpmap:32 MPV/90000 maudio 53122 RTP/AVP 110 artpmap:110telephone-events/8000 asendonly 4、后继 基于SDP的提议应答模型的实际实现需要依赖于某种呼叫信令协议比如SIP、BICC等等相比较而言与提议应答模型这些协议的关系更为复杂。本博客将有后继博文介绍在SIP中应用SDP提议应答模型的情况。
