此圖例和以下討論均來自于互聯(lián)網(wǎng)資源

　　在后續(xù)的章節(jié)中，我們將討論answer如何回應(yīng)offer，會(huì)話修改的細(xì)節(jié)處理，向?qū)Ψ街甘緟f(xié)商能力，offer/answer交互模式的拓展ICE。

　　首先，我們介紹一下我們討論的基本背景環(huán)境。到目前為止，我們討論的核心話題涉及了SDP和準(zhǔn)備要討論的offer/anser交互模式�；�本上我們都是圍繞兩個(gè)核心的規(guī)范來討論，其中，RFC4566（SDP）為基本藍(lán)圖，然后配合RFC3264關(guān)于offer/answer交互模式。關(guān)于SDP的內(nèi)容，我們?cè)谇懊娴恼鹿?jié)已經(jīng)有完整的介紹（SDP基礎(chǔ)），那個(gè)章節(jié)涵蓋了SDP的核心定義/專有名詞，語法，特征屬性，使用場景等相關(guān)細(xì)節(jié)，讀者可以查閱上一個(gè)章節(jié)的內(nèi)容，這里不再贅述。根據(jù)上一個(gè)章節(jié)的內(nèi)容，我們?cè)诒菊鹿?jié)進(jìn)一步討論SDP協(xié)商時(shí)使用的交互模式-offer/answer模式。在本章節(jié)，我們將重點(diǎn)以RFC3264為藍(lán)本，介紹offer/anwer交互模式。筆者主要以offer和answer兩個(gè)部分為核心主線，分別按照兩個(gè)部分中的單播媒體和多播媒體的處理方式的不同來展開討論。這里提醒讀者，為了更好地支持IPv4，在RFC3264的基礎(chǔ)上，RFC6157對(duì)媒體描述管理進(jìn)行了更新。因此，如果讀者涉及了在IPv6環(huán)境中關(guān)于SDP中的媒體描述，讀者可以查閱RFC 6157-4.1章節(jié)的細(xì)節(jié)。如果讀者對(duì)SDP協(xié)商模式有興趣的話，可以結(jié)合具體的代碼示例來做進(jìn)一步的研究。以下示例是開源SIP協(xié)議棧-PJSIP中關(guān)于SDP協(xié)商狀態(tài)機(jī)的處理流程示意圖：

　　鏈接：https://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__SDP__NEG.htm#details

　　很多技術(shù)人員，一說到offer/answer交互模式，就不假思索說這個(gè)概念其實(shí)非常簡單。事實(shí)上，很多人對(duì)此概念有不少誤解或者還在半桶水的認(rèn)知狀態(tài)。因?yàn)楹芏嗉夹g(shù)人員經(jīng)常排除的問題基本上都是一個(gè)簡單的雙方呼叫（單播會(huì)話），排查的交互會(huì)話描述也就雙方的會(huì)話參數(shù)，并沒有涉及到多播會(huì)話使用場景，例如IP廣播，會(huì)議等處理。另外，關(guān)于單播和多播場景中的RTP媒體流的處理也非常不同（可參考RFC 6284-7.1.2的端口映射），需要讀者對(duì)這些概念有一個(gè)充分的理解。因此，很多具體的協(xié)商需要大家了解。

　　此圖片以及以下圖例均來自互聯(lián)網(wǎng)資源

　　我們需要首先提醒讀者這些問題，在offer/answer交互模式下，單播會(huì)話和多播會(huì)話的處理方式是有差別的。SDP（RFC 4566）當(dāng)時(shí)設(shè)計(jì)的構(gòu)想是提供一種方式來描述多播骨干網(wǎng)中傳輸?shù)亩嗖��?huì)話。SAP（RFC 2947）的設(shè)計(jì)構(gòu)想是作為一種多播機(jī)制傳輸SDP消息的。在很多業(yè)務(wù)場景中，雖然規(guī)范中支持也允許支持單播操作，但是規(guī)范中支持單播操作相對(duì)不太完整。多播會(huì)話操作需要覆蓋全部會(huì)話參與者的操作，單播會(huì)話則僅涉及了兩個(gè)參與者以及其各自的認(rèn)同的工作參數(shù)。具體來說，多播會(huì)話比單播會(huì)話涉及了更多的關(guān)于處理機(jī)制和處理方式，在offer/answer交互模式下有不同的處理方式。因此，提醒讀者，我們?cè)谙旅娴挠懻撝校�針�?duì)各種環(huán)境都會(huì)分別介紹單播會(huì)話和多播會(huì)話的處理方式，希望讀者千萬不要迷惑。例如，如果是多播會(huì)話的話，它要求針對(duì)具體的媒體流對(duì)所有參與方地址發(fā)送一個(gè)單多播地址，如果是單播會(huì)話的話，它僅需要雙方的兩個(gè)地址即可。再比如，如果是多播會(huì)話的話，它僅要求標(biāo)識(shí)出會(huì)話所使用的具體編碼即可，通知所有會(huì)話參與方僅使用標(biāo)識(shí)的編碼，但是，如果是單播會(huì)話中，則需要列出一個(gè)編碼支持列表，雙方可能都支持某些重復(fù)的編碼，通過二次協(xié)商才能決定使用何種編碼。另外，讀者可以想象一下，在單播會(huì)話環(huán)境中，隨著技術(shù)和網(wǎng)絡(luò)環(huán)境的不斷發(fā)展，終端支持的各種編碼或者協(xié)商標(biāo)識(shí)越來越多，盡管雙方的SDP提供了豐富的足夠的會(huì)話描述信息，但是因?yàn)闀?huì)話描述定義越來越多，它們所帶來的問題也越來越多，例如定義的語法格式問題，操作細(xì)節(jié)的統(tǒng)一性問題。因此，會(huì)話雙方究竟如何成功協(xié)商，在技術(shù)方面，這仍然存在很多爭議，這也直接導(dǎo)致了很多環(huán)境下，軟硬件終端包括服務(wù)器端的雙方SDP協(xié)商不成功的問題。因此，為了實(shí)現(xiàn)協(xié)商的簡化和規(guī)范化，RFC 3264基于SDP規(guī)定了一種簡化的offer/answer 交互模式。接下來，我們簡單介紹一下其基本工作原理。

　　在offer/answer交互模式環(huán)境中，會(huì)話中的發(fā)起方（offerer）生成一個(gè)offer數(shù)據(jù)，offer中包括媒體流參數(shù)和傳輸編碼，希望接收媒體的IP地址和端口。offer數(shù)據(jù)傳遞到對(duì)端接收方（answerer），接收方也生成一個(gè)answer數(shù)據(jù)回復(fù)給offerer發(fā)起方，在answer回復(fù)數(shù)據(jù)中包含了已匹配的媒體會(huì)話描述參數(shù)，表示其媒體是否可以接受。然后通過協(xié)商好的傳輸編碼，通過offer消息中的地址和端口對(duì)offerer發(fā)起方發(fā)送媒體流。無論是單播會(huì)話還是多播會(huì)話都可以支持offer/answer交互模式。注意，讀者如果對(duì)交互模式下的offer/offerer和answer/answerer有歧義，最好查閱SDP基礎(chǔ)章節(jié)中核心定義全解的內(nèi)容。

　　現(xiàn)在，我們討論一些關(guān)于協(xié)議層操作的流程。offer/answer模式工作的前提基于一些高級(jí)協(xié)議，例如SIP協(xié)議存在，SIP協(xié)議有能力支持SDP的協(xié)商來實(shí)現(xiàn)基于代理之間的對(duì)會(huì)話創(chuàng)建支持。協(xié)議層的操作從一方代理對(duì)另外一方發(fā)起初始化的offer開始。對(duì)端的代理可以接受offer，并且返回一個(gè)answer或者拒絕這個(gè)offer。拒絕offer取決于高級(jí)協(xié)議層。這里強(qiáng)調(diào)一點(diǎn)，offer/answer交互模式是atomic級(jí)的，這表示它具有一定的制鎖功能。如果這個(gè)answer被拒絕的話，會(huì)話將回復(fù)到offer之前的狀態(tài)。任何時(shí)間其中一個(gè)代理都可以生成一個(gè)新的offer來更新此會(huì)話狀態(tài)。但是，如果代理已經(jīng)收到了一個(gè)offer，代理還沒有接受或者拒絕，此代理一定不能生成新的offer。此外，如果代理已經(jīng)生成了一個(gè)較早的offer，這個(gè)代理在還沒有收到針對(duì)較早的offer返回的answer消息或者拒絕消息，此代理一定不能生成一個(gè)新的offer。簡單來說，就是代理在沒有收到較早offer的回應(yīng)結(jié)果（應(yīng)答或者拒絕）之前，它一定不能再生成一個(gè)新的offer。有時(shí)，我們可能會(huì)看到一種特殊狀態(tài)，代理已經(jīng)發(fā)送了一個(gè)offer后，但是在沒有收到此offer的answer前，如果代理收到了一個(gè)offer的話，這種狀態(tài)稱之為 “glare condition”。

　　雙方代理可能同時(shí)對(duì)對(duì)方發(fā)送一個(gè)更新offer。這種特殊情況下的處理機(jī)制需要更高層協(xié)議來對(duì)這種特殊狀態(tài)進(jìn)行數(shù)據(jù)包發(fā)送到排序處理。如果讀者對(duì)glare case 或者異常處理有興趣做進(jìn)一步研究的話，可以參考RFC 6337-4章節(jié)。接下來，我們開始討論生成offer的流程處理，以及在生成初始化offer中關(guān)于單播媒體和多播媒體的處理方式。

　　我們討論生成offer消息之前，首先我們一定要確定，無論是offer消息還是answer消息，它們一定是一個(gè)有效的SDP消息。

　　在SDP中針對(duì)offer/answer的構(gòu)成語法可以忽略“e”或者“p=”行。筆者不清楚為什么在offer/answer的消息中可以忽略“e”或者“p=”行，難道因?yàn)檫@兩個(gè)會(huì)話描述不是十分重要的協(xié)商參數(shù)？ “o“行中的會(huì)話ID的數(shù)值和版本號(hào)必須是一個(gè)64位的有符號(hào)整形數(shù)，并且版本的初始值必須小于（2**62） ? 1，這樣可以防止翻轉(zhuǎn)。在SDP規(guī)范中，可以允許多個(gè)SDP會(huì)話描述拼接在一起構(gòu)成一個(gè)大的SDP消息，但是SDP消息使用在offer/answer交互模式下時(shí)，一個(gè)SDP消息必須包含一個(gè)完整的會(huì)話描述。

　　讀者知道，SDP中的"s="傳遞會(huì)話主題，這種定義方式對(duì)多播會(huì)話方式是非常合理的，但是對(duì)單播會(huì)話方式存在一定問題。因此，一般推薦是”s“行有一個(gè)單空格字符或一個(gè)破折號(hào)構(gòu)成。SDP "t="行負(fù)責(zé)傳遞會(huì)話時(shí)間，通常情況下，對(duì)單播會(huì)話的媒體來說，它的創(chuàng)建或者結(jié)束一般來自于外部的信令的控制，例如，我們現(xiàn)在討論的SIP協(xié)議。那種情況下，"t="行應(yīng)該設(shè)定為”0 0.“。

　　offer消息中包含零個(gè)或者多個(gè)媒體流，每個(gè)媒體流通過”m=“行的媒體會(huì)話和其關(guān)聯(lián)特征屬性進(jìn)行說明。讀者可能不明白，為什么offer消息中可能會(huì)包含零媒體信息？其實(shí)，包含零媒體仍然有它的原因。如果offer消息中包含零個(gè)媒體，這表示發(fā)起方-offerer希望和對(duì)端通信，但是發(fā)起方會(huì)在將來某一時(shí)間時(shí)間在此會(huì)話中添加那個(gè)媒體，添加媒體的方式是通過發(fā)送一個(gè)修改的offer來處理。 此媒體可以是一個(gè)單播和多播的混合。如果是多播的媒體，那offer消息中需要在"c="行添加多播地址。它們的構(gòu)成方式取決于它們的媒體是單播還是多播媒體。簡單理解，這里的零媒體不是表示offer沒有什么可做，這表示發(fā)起方可能將來在某一時(shí)間發(fā)起媒體流，但是不是現(xiàn)在。如果將來發(fā)起媒體流，offerer會(huì)更新offer再次提醒對(duì)端answerer。下面，我們繼續(xù)討論offer中的單播媒體場景的處理流程。

　　這里，我們花費(fèi)一點(diǎn)時(shí)間需要詳細(xì)說明offer中的單播媒體處理流程。在offer中的單播媒體處理中，offer對(duì)媒體的發(fā)送和接收標(biāo)注涉及了多個(gè)方向指示特征屬性（a=sendonly，a=recvonly，a=sendrecv，a=inactive-參考RFC3108和RFC2327），多個(gè)特征屬性又具有不同的含義，所以請(qǐng)讀者在閱讀本部分內(nèi)容時(shí)一定要特別注意。讀者也可以查閱筆者的歷史文檔來學(xué)習(xí)關(guān)于這三種屬性應(yīng)用場景示例。

　　如果offer僅希望對(duì)對(duì)端發(fā)送媒體時(shí)，offer必須對(duì)此媒體標(biāo)注為send-only的表示，通過特征屬性"a=sendonly"行來標(biāo)識(shí)。如果媒體發(fā)送的方向?qū)傩宰鳛槊襟w媒體流屬性或者會(huì)話屬性出現(xiàn)的話，我們就會(huì)認(rèn)為此媒體標(biāo)注了媒體發(fā)送方向。同理，如果此offer僅希望從對(duì)端接收媒體的話，offer必須對(duì)此媒體標(biāo)識(shí)為recvonly，表示僅為接收狀態(tài)，通過特征屬性“a=recvonly”表示。如果，offer希望和對(duì)端通信，但是，此時(shí)，offer既不想發(fā)送媒體也不行接收媒體時(shí)，它通過對(duì)媒體標(biāo)識(shí)為"a=inactive"行來表示其當(dāng)時(shí)狀態(tài)。

　　這里，筆者需要提醒一下，因?yàn)楹芏嘧钚碌囊?guī)范已經(jīng)對(duì)RTP協(xié)議的實(shí)時(shí)應(yīng)用程序傳輸協(xié)議-RFC3550進(jìn)行了更新（包括5761，6051，6222，7022，7160，7164，8083和8108），因此一些特別的處理流程需要提醒讀者。如果是涉及了RFC3550中描述的實(shí)時(shí)傳輸協(xié)議和實(shí)時(shí)傳輸控制需要的話，為了支持以上三種方向指示的狀態(tài)，RTCP同樣需要被發(fā)送和接收。這種情況下，媒體流的方向指示不會(huì)影響RTCP的使用。如果offer希望對(duì)對(duì)端發(fā)送和接收媒體的話，它可以通過"a=sendrecv"行來標(biāo)識(shí)也可以忽略其屬性設(shè)置（因?yàn)榇藢傩詾槟�認(rèn)設(shè)置屬性）。

　　讀者需要注意，offer消息中三種媒體流向的方向有一些不同。對(duì)于標(biāo)記了“a=recvonly”和“a=sendrecv”的媒體流來說，在offer消息中，端口號(hào)和地址表示發(fā)起方offerer希望接收媒體流的端口和地址。對(duì)于標(biāo)識(shí)為“a=sendonly” RTP 媒體流，端口號(hào)和地址間接指示為offerer希望接收RTCP數(shù)據(jù)的地址。除非有明確表示說明，否則RTCP報(bào)表數(shù)據(jù)將會(huì)發(fā)送到比標(biāo)識(shí)的端口高一位的端口（這是默認(rèn)的RTCP端口發(fā)送方式）。很多時(shí)候，讀者可能對(duì)offer中的IP地址和端口使用有一些誤解，這里筆者做進(jìn)一步的解釋。在offer中出現(xiàn)的ip地址和端口不能指示將要由發(fā)起方offerer發(fā)送出去的RTP/RTCP的源地址，源端口。在offer消息中，如果端口數(shù)為零，這表示媒體已經(jīng)被經(jīng)過offer消息處理，但是此媒體一定不能被使用，因?yàn)榇顺跏嫉膐ffer中沒有任何有效的語法參數(shù)。有時(shí)，如果設(shè)置端口零可以結(jié)束現(xiàn)存的媒體流。一般來說，端口數(shù)量為零表示此媒體流不是offer/answer雙方需要的媒體流。但是，一些特殊的環(huán)境下，編碼類型一樣，但是可能因?yàn)閜ayload不同的話，也可能需要做一些協(xié)商處理。針對(duì)標(biāo)識(shí)為”a=sendonly“ 或“a=sendrecv”的媒體，在answer的消息中同樣的媒體可能標(biāo)識(shí)了不同的payload。offerer發(fā)起方收到answerer回復(fù)后，重新發(fā)送一個(gè)offer。這次發(fā)送中，offerer發(fā)起方必須包含一個(gè)和answer消息中一樣的媒體payload。這樣才能保證雙方的媒體的payload一致性。有時(shí)，為了保證和H323的兼容性，每個(gè)方向可以支持不同的payload類型號(hào)。

　　在所有的RTP流使用場景中，fmtp 媒體格式類型可能出現(xiàn)來支持更多的媒體格式類型描述。所有的媒體描述應(yīng)該包含"a=rtpmap"行，它用來映射相應(yīng)的payload 類型號(hào)碼來對(duì)編碼進(jìn)行編碼處理。如果沒有"a=rtpmap"行的話，應(yīng)該使用默認(rèn)的當(dāng)前的屬性設(shè)置（RTP/AVP）。具體默認(rèn)屬性設(shè)置，讀者可查閱RFC3551-6。

　　offer的協(xié)商過程中，讀者需要另外注意幾個(gè)經(jīng)常使用的媒體描述參數(shù)。在協(xié)商過程中，offer消息中必須提供一個(gè)"m="行的格式列表，通過偏好優(yōu)先級(jí)的順序來通知對(duì)端offer中推薦使用的優(yōu)先級(jí)編碼格式。優(yōu)先級(jí)最高的是最優(yōu)先使用的編碼格式。有時(shí)，我們?cè)谂渲密浗粨Q或者媒體服務(wù)器時(shí)，雙方呼叫失敗，有可能是編碼不匹配導(dǎo)致，比如說沒有匹配的prefered的編碼。所以，編碼列表的順序是非常重要的，技術(shù)人員需要對(duì)照服務(wù)器端的編碼列表實(shí)現(xiàn)對(duì)照本地終端的編碼列表順序檢查。比如FreeSWITCH中的編碼優(yōu)先級(jí)設(shè)置：

　　如果ptime特征屬性出現(xiàn)offer中，它表示offer所期望的收到的打包時(shí)長，當(dāng)然，ptime必須大于零。如果offer中出現(xiàn)了bandwidth的話，它表示offer所期望帶寬來傳輸媒體流。當(dāng)然，帶寬值也允許設(shè)置為零（不建議），這表示沒有媒體發(fā)送，同時(shí)也關(guān)閉了RTCP數(shù)據(jù)發(fā)送。

　　如果是offerer中的多媒體的話，根據(jù)多媒體類型的不同處理方式也有一定的差別。如果在offer中出現(xiàn)了不同類型的多媒體流（語音，視頻，文本等），這表示發(fā)起方offerer希望同時(shí)使用這些多媒體流。比較典型的例子就是視頻會(huì)議，視頻會(huì)議中，語音和視頻媒體流被同時(shí)使用。如果在offer中出現(xiàn)來同樣的媒體類型的話，這表示offerer發(fā)起方期望同時(shí)接收或發(fā)送那種同一類型的媒體流。關(guān)于同一類型的媒體流收發(fā)，雙方可能有一定的規(guī)則策略需要遵守，這取決于本地資源（例如，麥克風(fēng)/攝像頭和錄像終端）和業(yè)務(wù)需求的設(shè)置。另外一些限制也可能影響多媒體的本地處理策略，例如不同語音或者視頻媒體流的混音/混屏處理，按需錄像錄音處理等業(yè)務(wù)需求。

　　Offerer發(fā)送方需要根據(jù)不同的指示標(biāo)識(shí)調(diào)整為一個(gè)相應(yīng)的狀態(tài)。一旦發(fā)起方Offerer發(fā)送了offer消息以后，發(fā)起方必須準(zhǔn)備接收offer描述的任何標(biāo)識(shí)為recvonly的媒體。另外，發(fā)起方必須準(zhǔn)備發(fā)送和接收在offer中標(biāo)識(shí)為sendrecv的媒體，并且準(zhǔn)備發(fā)送在offer中標(biāo)識(shí)為sendonly的媒體。當(dāng)然，何時(shí)發(fā)送還要取決于對(duì)端answer的地址和端口。在RTP的環(huán)境中，雖然可能offerer在answer消息到達(dá)之前，提前收到了媒體流，但是發(fā)起方仍然需要收到answer消息后，它才能發(fā)送RTCP接收方報(bào)告數(shù)據(jù)。

　　在offer中，如果一個(gè)會(huì)話描述中包含一個(gè)多播媒體流，此多播媒體流列為僅接收或者發(fā)送狀態(tài)，這表示參與者（包括了發(fā)起方offerer和接收方answerer）僅能接收或發(fā)送媒體流。和多播媒體流處理方式相比，單播媒體處理僅是發(fā)起方和接收方媒體流的直接收發(fā)。除了以上這個(gè)區(qū)別以外，offer中的多播媒體的語法定義可以查閱RFC4566的規(guī)范說明。

　　https://www.rfc-editor.org/rfc/rfc3264

　　https://tools.ietf.org/html/rfc6284

　　https://tools.ietf.org/html/rfc5939

　　https://www.pjsip.org/pjmedia/docs/html/group__PJMEDIA__SDP__NEG.htm