基于SDP的提议/应答（offer/answer）模型简介
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如下：
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
被叫B不想發送和接收第一個視頻流，所以返回以下SDP作為應答。（注意描述第一個視頻流的"m="行中端口設為0，這表示拒絕這個媒體流）。
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
之后的某一時刻，B決定改變其接收音頻流的端口(從49920 改為65422)，同時，增加另一個“僅接收”的音頻流（注意其屬性為recvonly），使用 RTP 凈荷類型 events 。
B提供了以下SDP作為提議：
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110telephone-events/8000
a=recvonly
A接受這個新增的媒體流（注意在其屬性為sendonly），所以產生以下的應答：
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110telephone-events/8000
a=sendonly
4、后繼
基于SDP的提議應答模型的實際實現需要依賴于某種呼叫信令協議，比如SIP、BICC等等，相比較而言，與提議應答模型這些協議的關系更為復雜。本博客將有后繼博文介紹在SIP中應用SDP提議應答模型的情況。
總結
以上是生活随笔為你收集整理的基于SDP的提议/应答（offer/answer）模型简介的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： boost asio 简单示例
- 下一篇： RTP协议之Header结构解析