前面的章節(jié)包括上一次筆者發(fā)布的文章中，筆者分別討論了offer和answer雙方的消息生成。這里，筆者將討論會(huì)話(huà)的修改。修改會(huì)話(huà)是常見(jiàn)的業(yè)務(wù)場(chǎng)景，通過(guò)修改會(huì)話(huà)實(shí)現(xiàn)另外一個(gè)新的流程。在會(huì)話(huà)的某個(gè)點(diǎn)上，任何會(huì)話(huà)參與方都可以發(fā)出一個(gè)新的offer來(lái)修改會(huì)話(huà)的屬性參數(shù)。會(huì)話(huà)修改是offer/answer交互模式的基本操作，它的處理流程其實(shí)和我們前面討論的流程完全一致，通過(guò)某些流程修改現(xiàn)存會(huì)話(huà)的某些參數(shù)。offer可能和以前的相同，也可能和以前的不同。當(dāng)討論修改會(huì)話(huà)時(shí)，我們需要涉及上一個(gè)或者前面的SDP，上一個(gè)SDP提供了其他的會(huì)話(huà)參數(shù)基礎(chǔ)，這些參數(shù)可能已經(jīng)在offer或者answer消息中存在�，F(xiàn)在，筆者先說(shuō)明一下修改會(huì)話(huà)的一些基本框架和前提條件。如果offer相同，answer可能和從answerer獲得的上一個(gè)SDP中的相同，也可能answer不同。如果已提供的SDP和前面的SDP不同，一些特定的限制需要注意。關(guān)于這些限定，筆者在后續(xù)部分討論。理論上說(shuō)，幾乎所有的會(huì)話(huà)屬性都可以修改。例如，可以增加一個(gè)媒體流，可以刪除現(xiàn)存媒體流，可以修改現(xiàn)存媒體流參數(shù)。當(dāng)發(fā)起一個(gè)offer，此offer修改需要修改會(huì)話(huà)時(shí)，除了origin域值其版本號(hào)必須在前面的SDP版本號(hào)基礎(chǔ)上增加一位數(shù)以外，新SDP中的"o="行必須等同于前面的SDP中的"o="行。如果在新SDP中，origin域值不能增加的話(huà)，此SDP必須等同于同一origin值域的SDP。answerer應(yīng)答方必須準(zhǔn)備接收offer，此offer包含一個(gè)無(wú)改變origin值域版本的SDP。根據(jù)筆者在前面應(yīng)答方生成answer的流程，雖然answerer接收了這樣的一個(gè)offer，然而，answerer仍然必須生成一個(gè)有效的answer消息（此answer消息可能和以前SDP相同不同，也可能不同）。如果已提供的SDP和前面的SDP不同的話(huà)，這個(gè)新的SDP必須有一個(gè)媒體流和前面的SDP媒體流中的匹配。換句話(huà)說(shuō)，如果前面的SDP有四個(gè)"m="行，那么在新的SDP中必須至少有四個(gè)"m="行。前面SDP中的媒體流排序（從最頂端計(jì)數(shù)）關(guān)系必須匹配新的SDP中的媒體流排序（從最頂端計(jì)數(shù)）關(guān)系。為什么需要這樣的匹配關(guān)系呢？其實(shí)，這樣的匹配關(guān)系是非常必要的，answerer應(yīng)答方?jīng)Q定新的SDP中某個(gè)媒體流可以對(duì)應(yīng)前面SDP中的那個(gè)媒體流，然后可以綁定SDP媒體流的具體的匹配關(guān)系，否則，修改會(huì)話(huà)就會(huì)出現(xiàn)數(shù)據(jù)混亂。因?yàn)闉榱藵M(mǎn)足以上的這些要求，我們看到，媒體流中的"m="行從來(lái)不會(huì)減少，“m=”行數(shù)保持不變或者增加。另外，從前面SDP中刪除的媒體流一定不能從新SDP中移除，不過(guò)，這些媒體的屬性不能出現(xiàn)在新的SDP中。

　　通過(guò)Offer/Answer 交互模式修改會(huì)話(huà)描述

　　新的媒體流可以通過(guò)添加一個(gè)新的媒體描述來(lái)實(shí)現(xiàn)，它可以添加到當(dāng)前媒體描述的下面，也可以重新使用舊的媒體流的空間來(lái)重新激活新的媒體流。注意，這里，舊的媒體流通過(guò)端口設(shè)置為零以后已經(jīng)被關(guān)閉。如果新的媒體流使用舊媒體流空間的話(huà)，新媒體描述需要替換掉舊的媒體描述，但是新媒體描述應(yīng)該在SDP中和其他媒體描述位置不變。新媒體描述必須出現(xiàn)在已存在媒體描述的下面（這是一個(gè)格式規(guī)則）。當(dāng)answerer應(yīng)答方收到的SDP中所包含的媒體描述比offerer發(fā)起方發(fā)送的媒體描述多時(shí)，或者收到的SDP中包含媒體流，此媒體流占用的以前舊媒體流空間的話(huà)（端口為零），應(yīng)答方就知道這里增加了一個(gè)新的媒體流。當(dāng)然，新增加的媒體流也可以通過(guò)answer消息，在answer重構(gòu)媒體描述接受或者拒絕這個(gè)新的媒體流。關(guān)于應(yīng)答發(fā)生成answer的流程，讀者需要參考前面的章節(jié)。

　　除了在會(huì)話(huà)中增加媒體流以外，媒體流當(dāng)然也可以被從會(huì)話(huà)中移除。如果要移除媒體流的話(huà)，需要?jiǎng)?chuàng)建一個(gè)新的SDP，在新的SDP中對(duì)需要移除的媒體流端口設(shè)置為零，這樣就移除了媒體流。媒體描述可以忽略以前出現(xiàn)的所有描述，僅保留單個(gè)媒體格式。所有在offer消息中出現(xiàn)被標(biāo)識(shí)為關(guān)閉的媒體流（端口設(shè)置為零）也必須在anwer標(biāo)識(shí)這些媒體流，并且關(guān)閉端口。反之，answer也必須針對(duì)offer做同樣的處理流程。在這種情況下，RTP和RTPC的傳輸流程也會(huì)停止退出，釋放任何和這些媒體關(guān)聯(lián)的資源，例如占用的電腦麥克風(fēng)，攝像頭資源也會(huì)關(guān)閉。

　　除了增加媒體流，刪除媒體流以外，本章節(jié)開(kāi)始時(shí)，筆者說(shuō)過(guò)，幾乎所有的會(huì)話(huà)中的媒體流屬性參數(shù)都可以修改�，F(xiàn)在，我們主要介紹一下修改地址，端口，傳輸方式，媒體格式，媒體類(lèi)型，屬性，以及單播媒體等待狀態(tài)處理。

　　媒體的端口號(hào)是可以被修改的。筆者將討論offerer和answerer兩個(gè)方向的端口修改。如果要修改媒體的端口號(hào)，發(fā)起方offerer需要?jiǎng)?chuàng)建一個(gè)新的會(huì)話(huà)描述，在新會(huì)話(huà)描述中的“m=”行包含一個(gè)端口號(hào)，此端口號(hào)必須和前面相應(yīng)媒體SDP中的會(huì)話(huà)描述中的端口號(hào)不同。如果僅修改端口號(hào)，那么其他的媒體描述應(yīng)該保持不變狀態(tài)。因?yàn)閛fferer修改了端口以后，還沒(méi)有收到任何answer消息之前，所以，只要offerer發(fā)送了offer以后，offerer發(fā)起方必須準(zhǔn)備接收舊端口發(fā)送過(guò)來(lái)的媒體和新端口發(fā)送過(guò)來(lái)的媒體。直到收到了answer消息，媒體流從新端口抵達(dá)，offerer發(fā)起方才能退出舊端口的偵聽(tīng)。簡(jiǎn)單來(lái)說(shuō)，在使用新端口的媒體抵達(dá)之前，發(fā)起方不應(yīng)該退出舊端口的偵聽(tīng)，否則，可能出現(xiàn)傳輸?shù)拿襟w丟失的問(wèn)題。需要特別注意到是，這里存在一個(gè)新舊端口切換的過(guò)渡階段，可能一些應(yīng)用場(chǎng)景中的已接收到媒體流。這里的已接收到媒體可能已經(jīng)被存放在了一個(gè)系統(tǒng)的存儲(chǔ)節(jié)點(diǎn)上，如果有一個(gè)緩沖區(qū)的處理列表的話(huà)，接收方用戶(hù)終端會(huì)繼續(xù)偵聽(tīng)舊端口來(lái)的這個(gè)媒體流，直到從新端口接收到的媒體流存放在優(yōu)先級(jí)最高的空間，這樣，接收方終端才會(huì)退出舊端口的媒體偵聽(tīng)，真正開(kāi)始偵聽(tīng)新端口的媒體。

　　前面，筆者討論了offerer發(fā)起方的端口修改，現(xiàn)在開(kāi)始討論answerer的端口修改。在answer中相應(yīng)的媒體流可以和前面answerer發(fā)送的SDP中的媒體流相同也可能不同。如果應(yīng)答發(fā)接受了一個(gè)已更新的媒體流，應(yīng)答方應(yīng)該使用新的端口馬上開(kāi)始發(fā)送此更新的媒體流數(shù)據(jù)。如果應(yīng)答方從前面的SDP的端口改變了發(fā)送端口，只要answer消息發(fā)送后，answerer應(yīng)答方必須準(zhǔn)備同時(shí)從新端口和舊端口接收媒體流數(shù)據(jù)。關(guān)于新端口和舊端口的偵聽(tīng)退出和offerer的思路完全相同，筆者這里不再重復(fù)。以上我們討論的是answerer接受了offer的更新媒體。如果answerer應(yīng)答方拒絕了offer的媒體流，offerer發(fā)起方收到拒絕消息后，offerer會(huì)停止前面準(zhǔn)備接收媒體的端口。

　　改變媒體發(fā)送地址的處理方式和改變端口的處理方式相同，區(qū)別在于其連接屬性“c=”需要更新，端口沒(méi)有修改。媒體傳輸方式也可以修改，處理方式和端口的處理方式是相同的，傳輸方式修改，其端口不能修改。

　　除了會(huì)話(huà)中修改地址，端口和傳輸方式以外，會(huì)話(huà)管理的另外一個(gè)功能就是修改媒體格式。在會(huì)話(huà)中支持的媒體列表中的任何一個(gè)媒體格式都可以被修改。如果需要修改媒體格式的話(huà)，offer需要?jiǎng)?chuàng)建一個(gè)媒體描述，在這個(gè)新的媒體描述中，"m="行的媒體格式列表和此媒體流前面SDP中的不同。在新的會(huì)話(huà)描述中，此媒體列表可以增加新的媒體格式，也可以刪除出現(xiàn)在前面SDP中的媒體格式。具體到RTP的使用中，在此媒體流中，會(huì)話(huà)期間的這個(gè)匹配關(guān)聯(lián)關(guān)系一定不能被修改，具體來(lái)說(shuō)，這個(gè)綁定關(guān)聯(lián)關(guān)系是從一個(gè)指定的動(dòng)態(tài)payload類(lèi)型匹配到一個(gè)指定的編碼，它們兩者之間綁定關(guān)系在此會(huì)話(huà)生命周期內(nèi)是不能修改的。例如，如果Bob端生成了一個(gè)offer消息，此offer消息中標(biāo)識(shí)了編碼格式G.711綁定到了一個(gè)動(dòng)態(tài)的payload 類(lèi)型號(hào)46，在此會(huì)話(huà)期間，在此媒體流中，無(wú)論是offer或者answer，這個(gè)46 payload 類(lèi)型號(hào)碼一定是表示G.711編碼格式。但是，多個(gè)payload 類(lèi)型號(hào)映射到同一編碼格式的這種情況也是可以接受的。因此，一個(gè)已更新的offer消息中可以使用其他payload 類(lèi)型號(hào)碼來(lái)映射G.711編碼，例如，也可以在更新的offer中使用payload type是72來(lái)映射G.711編碼。

　　Asterisk-18中編碼協(xié)商處理流程示例

　　顯而易見(jiàn)，為了保證SDP信令交互和媒體流之間的同步，在一個(gè)會(huì)話(huà)期間，動(dòng)態(tài)payload號(hào)類(lèi)型和編碼的映射關(guān)系必須維持一個(gè)固定狀態(tài)。我們?cè)谇懊娴恼鹿?jié)介紹過(guò)在answer中相應(yīng)的媒體流構(gòu)建，構(gòu)建的過(guò)程也可能導(dǎo)致修改媒體格式。同樣的，只要應(yīng)答方發(fā)送answer應(yīng)答消息，answerer應(yīng)答方必須開(kāi)始使用某種媒體格式發(fā)送媒體流，這種媒體格式出現(xiàn)在answer消息中，也出現(xiàn)在了其offer消息中，answerer應(yīng)該使用offer中優(yōu)先級(jí)最高的推薦媒體格式（此媒體格式也出現(xiàn)answer中的媒體格式）。即使某種媒體格式出現(xiàn)在前面的SDP中，如果此媒體格式?jīng)]有出現(xiàn)在offer中的話(huà)，answerer一定不能使用這種媒體格式。反之亦然，offerer發(fā)起方收到answer后，它發(fā)送媒體時(shí)必須使用answer中優(yōu)先級(jí)最高的媒體格式。即使某種媒體格式在前面的SDP中出現(xiàn)過(guò)，但是在本answer中沒(méi)有出現(xiàn)的話(huà)，offerer發(fā)起方一定不能使用此媒體格式。當(dāng)終端agent停止使用某種媒體格式時(shí)（這種媒體格式不在offer或answer消息中），它仍然需要在將來(lái)一定時(shí)間內(nèi)準(zhǔn)備使用此媒體格式接收媒體。這里，agent仍然需要做一個(gè)狀態(tài)處理。它自己本身如何知道何時(shí)停止使用某種媒體格式接收媒體流呢？它需要一些必要的技巧來(lái)處理，使得agent變得“聰明”一點(diǎn)，它可以判斷對(duì)端是否停止使用舊媒體格式。第一種處理技巧，agent可以修改端口來(lái)修改媒體格式。當(dāng)媒體抵達(dá)新端口后，agent知道對(duì)端peer已經(jīng)停止使用舊媒體格式發(fā)送媒體流，agent也能停止使用此媒體格式接收媒體流。這種處理方式的好處是不依賴(lài)于媒體格式，但是，如果涉及了加密處理的話(huà)，修改端口要求原來(lái)預(yù)留的資源也要做出改變，原來(lái)安全加密的密鑰需要重新簽發(fā)。接下來(lái)，我們討論第二種處理技巧，當(dāng)一個(gè)媒體格式被棄用時(shí)，agent使用一組全新的payload動(dòng)態(tài)類(lèi)型來(lái)映射所有的編碼。agent收到媒體時(shí)，它使用了新payload類(lèi)型中的其中一種格式的話(huà)，agent知道對(duì)端已經(jīng)停止使用就媒體格式發(fā)送媒體流。和第一種方式相比，這種方式不會(huì)影響預(yù)留資源和加密處理，但是需要增加額外的空間重新創(chuàng)建新payload 類(lèi)型號(hào)。最后一種方式是使用定時(shí)器。當(dāng)agent收到一個(gè)從對(duì)端peer發(fā)送過(guò)來(lái)的SDP，agent設(shè)置一個(gè)定時(shí)器。當(dāng)定時(shí)器被觸發(fā)后，agent就停止使用舊的媒體格式來(lái)接收媒體流。定時(shí)器設(shè)置為一分鐘的超時(shí)設(shè)置是完全沒(méi)有問(wèn)題的。在一些使用環(huán)境中，agent也可以不用考慮是否繼續(xù)使用舊媒體格式接收媒體流。因此，agent也無(wú)需過(guò)多干預(yù)。如果agent拒絕了offer的媒體流，對(duì)端也收到拒絕消息后也會(huì)停止準(zhǔn)備使用任何新媒體格式發(fā)送媒體流。第三種方式相對(duì)比較適用于簡(jiǎn)單的環(huán)境中，通過(guò)定時(shí)器超時(shí)來(lái)處理媒體格式的修改響應(yīng)。

　　除了前面我們討論的一些媒體描述參數(shù)可以修改以外，媒體類(lèi)型（語(yǔ)音，視頻，數(shù)據(jù)等）也可以進(jìn)行修改。對(duì)流媒體來(lái)說(shuō)，媒體類(lèi)型也可以通過(guò)一定的處理方式來(lái)修改。一般的推薦方式是，如果傳輸?shù)倪壿嫈?shù)據(jù)是一樣的，如果修改媒體類(lèi)型的話(huà)，可以通過(guò)不同的媒體格式來(lái)實(shí)現(xiàn)。以前比較常見(jiàn)的示例是傳真部署中的場(chǎng)景，基于VBD（Voiceband Data）的傳真和模擬傳真信號(hào)的媒體類(lèi)型修改。在當(dāng)媒體流修改為不同的媒體類(lèi)型。Voiceband Data和傳統(tǒng)傳真是分離的兩種類(lèi)型，它們可以在路由器，網(wǎng)關(guān)和IPPBX之間進(jìn)行類(lèi)型修改支持傳真功能。如果需要修改媒體類(lèi)型的話(huà)，offerer方使用一個(gè)新的媒體類(lèi)型創(chuàng)建一個(gè)新的媒體描述，替代掉前面SDP中需要修改的媒體類(lèi)型。在answer中相應(yīng)的媒體流需要遵從筆者前面討論的answer消息中構(gòu)建流程。假設(shè)媒體流被接受的話(huà)，只要answerer應(yīng)答方收到了offer以后，它應(yīng)該開(kāi)始通過(guò)新的媒體類(lèi)型和格式發(fā)送媒體流。收到answer消息后，發(fā)起方offerer必須準(zhǔn)備使用舊媒體類(lèi)型和新媒體類(lèi)型接收媒體流，新媒體類(lèi)型的媒體流抵達(dá)后，新類(lèi)型媒體上升到播放緩沖區(qū)頂部，開(kāi)始正式使用最新媒體類(lèi)型。

　　修改會(huì)話(huà)中的特征屬性也需要通過(guò)offer/answer來(lái)修改。在媒體描述中其他的屬性也可以通過(guò)一個(gè)offer消息或answer消息來(lái)更新。一般情況下，如果agent收到了一個(gè)已修改參數(shù)的SDP，agent必須使用新的參數(shù)屬性發(fā)送媒體。

　　在以上所有的會(huì)話(huà)描述修改中，我們沒(méi)有涉及到一個(gè)非常普遍使用的應(yīng)用場(chǎng)景。這個(gè)使用場(chǎng)景就是呼叫等待功能。筆者再花費(fèi)一點(diǎn)時(shí)間來(lái)進(jìn)一步和大家說(shuō)明如何在呼叫等待狀態(tài)中處理單播媒體流。如果在呼叫中，一方（例如，A）把另外一方（例如，B）的呼叫執(zhí)行了電話(huà)?cǎi)v留，讓另外一方處于呼叫等待狀態(tài)（需要暫時(shí)停止發(fā)送一個(gè)或者多個(gè)單廣播媒體流）。這時(shí)，呼叫方A會(huì)對(duì)另一方B發(fā)送一個(gè)offer消息，offer消息中包含了一個(gè)更新的SDP。如果前面被停靠的媒體是一個(gè)被標(biāo)記為sendrecv的媒體流，現(xiàn)在，這個(gè)流媒體將會(huì)被替換成標(biāo)記為sendonly的媒體流。

　　如果前面被�？康拿襟w是一個(gè)被標(biāo)記為recvonly的媒體流，現(xiàn)在，這個(gè)流媒體將會(huì)被替換成標(biāo)記為inactive的媒體流。這樣的處理方式表示在每個(gè)方向�？康暮艚械却�媒體可以獨(dú)立分別標(biāo)識(shí)。等待狀態(tài)的媒體流都是各自獨(dú)立的。在等待狀態(tài)的媒體的offer消息的接收方不應(yīng)該自動(dòng)返回一個(gè)針對(duì)此等待狀態(tài)的answer消息。一個(gè)對(duì)所有等待狀態(tài)的媒體的SDP看作是已接受的SDP（held SDP）。當(dāng)answerer對(duì)已接受的SDP響應(yīng)SDP時(shí)，某些第三方的呼叫控制方案中，已接受的SDP不能正常工作。比較典型的應(yīng)用場(chǎng)景是，當(dāng)終端agent摁 "Hold" 按鍵時(shí)，agent端將會(huì)在SDP中對(duì)所有的流媒體生成一個(gè)offer消息，此offer消息表示一個(gè)sendonly指向，并且agent自己也執(zhí)行本地靜音，agent也沒(méi)有對(duì)遠(yuǎn)端發(fā)送媒體和播放媒體。還有很多的應(yīng)用遵從RFC 2543（不再使用），從規(guī)范規(guī)定通過(guò)連接地址設(shè)置為0.0.0.0來(lái)駐留呼叫。這種規(guī)范方式其實(shí)已不再推薦為一種�？糠绞�，并且也不能支持IPv6，它不能支持RTCP對(duì)媒體流的報(bào)表監(jiān)控。但是這種處理方式在初始o(jì)ffer時(shí)會(huì)非常有用。在發(fā)起時(shí)間，當(dāng)發(fā)起方offerer知道它想使用的具體的一組媒體流和它們的格式，但是此時(shí)還不知道接地址和端口，這種處理方式就滿(mǎn)足了初始o(jì)ffer的需求。Agent必須有一個(gè)支持能力來(lái)接收SDP，此SDP中的連接地址為0.0.0.0，關(guān)閉對(duì)RTP語(yǔ)音包數(shù)據(jù)或者RTCP報(bào)表數(shù)據(jù)的發(fā)送。關(guān)于呼叫等待的完整的流程介紹，讀者可以參考筆者歷史文檔：

　　最常用的18個(gè)SIP呼叫業(yè)務(wù)流程詳解-1-呼叫保持

　　在agent發(fā)送offer之前，如果知道offer中的媒體格式可以被遠(yuǎn)端answerer 應(yīng)答方接受的話(huà)，那將對(duì)agent有很大的幫助。SIP協(xié)議具有查詢(xún)能力，可以對(duì)對(duì)端進(jìn)行基本的能力查詢(xún)。在SIP響應(yīng)中的SDP可以用來(lái)指示對(duì)端的媒體支持能力。讀者可以查閱RFC 3261-11獲得關(guān)于查詢(xún)能力的介紹。這里，我們討論如何實(shí)現(xiàn)類(lèi)似SDP的構(gòu)建。可能一些讀者知道，其實(shí)，SDP沒(méi)有辦法指示此消息來(lái)說(shuō)明為了實(shí)現(xiàn)能力指示的目的，SDP只能進(jìn)行一些簡(jiǎn)單的能力查詢(xún)。它真正的的能力指示是由更高級(jí)的協(xié)議層內(nèi)容完成，SDP的基本能力指示的媒體承載能力是非常有限的。SDP本身不能表達(dá)允許參數(shù)值范圍，也不能通過(guò)offer/answer本身實(shí)現(xiàn)并行處理。SDP的這個(gè)局限性可能在未來(lái)的規(guī)范中得以支持。

　　使用一個(gè)結(jié)構(gòu)化的SDP表示媒體能力支持，其創(chuàng)建過(guò)程是這樣的。當(dāng)然，首先，此SDP必須是一個(gè)有效的SDP結(jié)構(gòu)，另外，它可以忽略"e=" 和 "p=" 行（前面討論已提及）。“t=”必須等于“0 0”。agent所支持的每個(gè)媒體類(lèi)型必須有相應(yīng)的媒體類(lèi)型的描述。在origin域中的會(huì)話(huà)ID是唯一的，唯一的會(huì)話(huà)ID用來(lái)支持每個(gè)已構(gòu)建的SDP指示其媒體能力。端口必須設(shè)置為零，但是連接地址可以是隨意的。如果一個(gè)SDP解析為offer或answer消息的話(huà)，使用端口為零的設(shè)置手段可以保證一個(gè)已經(jīng)構(gòu)建好的SDP不會(huì)引起媒體流創(chuàng)建，因?yàn)榇艘迅袷交�的SDP僅針對(duì)其支持能力，并且端口設(shè)置為零。"m="行表示傳輸?shù)拿襟w類(lèi)型。對(duì)于agent支持的媒體類(lèi)型中的每個(gè)媒體格式來(lái)說(shuō)，"m="行應(yīng)該有一個(gè)媒體格式列表。在RTP使用方面，如果使用了動(dòng)態(tài)payload類(lèi)型的話(huà)，rtmp屬性必須出現(xiàn)在SDP中，它用來(lái)綁定媒體類(lèi)型和具體的媒體格式。注意，在SDP中沒(méi)有辦法指示媒體限定，例如一種編碼可以支持的并發(fā)媒體流數(shù)量等。

　　在前面的幾個(gè)章節(jié)包括現(xiàn)在我們正在討論的章節(jié)中，筆者完整介紹了基本的語(yǔ)法概要，offer/answer各自生成消息的流程，還介紹了如何對(duì)會(huì)話(huà)中的媒體描述進(jìn)行管理。為了保證offer/answer交互模式規(guī)范的標(biāo)準(zhǔn)化，筆者在前面的所有章節(jié)中沒(méi)有涉及太多規(guī)范以外的內(nèi)容。此部分的內(nèi)容中，筆者結(jié)合幾個(gè)實(shí)例來(lái)具體說(shuō)明offer/answer的交互示例，終端/網(wǎng)關(guān)產(chǎn)品中關(guān)于媒體協(xié)商的示例，還有關(guān)于早期offer和后期offer的區(qū)別等延伸討論。說(shuō)明，因?yàn)槠�幅有限，在示例中，我們僅列出一般正常的交互方式，不涉及非常特別的或具體每個(gè)特殊場(chǎng)景的環(huán)境和參數(shù)討論。

　　首先讀者可以了解一個(gè)最簡(jiǎn)單的offer/answer交互模式的處理流程，示例中仍然是經(jīng)典的Alice/Bob舉例。這里，假設(shè)Alice在offer中已經(jīng)包含了以下的媒體描述，描述中一個(gè)雙向的語(yǔ)音媒體，兩個(gè)雙向的視頻媒體，其中視頻媒體使用了H.261（payload類(lèi)型是31）和MPEG（payload類(lèi)型是32）。這里，offer的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

　　Alice呼叫了Bob，但是，Bob不想接收或發(fā)送第一個(gè)視頻媒體流，因此Bob返回了一個(gè)answer消息：

　　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

　　在每個(gè)時(shí)間點(diǎn)，Bob想決定修改他的語(yǔ)音媒體流接收端口（從49920修改到65422），同時(shí)，他還要增加一個(gè)額外的媒體流，此媒體流標(biāo)識(shí)為receive指向狀態(tài)，使用的payload 類(lèi)型支持event（例如DTMF，傳真等）。關(guān)于event的介紹，讀者可以參考RFC4734-2。Bob會(huì)生成這樣的offer消息返回到Alice：

　　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:110 telephone-events/8000

　　a=recvonly  // 增加的指向

　　假設(shè)Alice接受了額外的媒體流支持請(qǐng)求，Alice生成以下answer：

　　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:110 telephone-events/8000

　　a=sendonly

　　通過(guò)幾次交互以后，完成雙方會(huì)話(huà)管理。以上交互流程實(shí)際上是Alice對(duì)Bob呼叫時(shí)的一個(gè)會(huì)話(huà)修改的流程，具體的協(xié)商響應(yīng)和回復(fù)需要參考筆者前面介紹的內(nèi)容。

　　多選一”One of N Codec“是編碼協(xié)商中比較常見(jiàn)的場(chǎng)景�，F(xiàn)在，很多物理SIP話(huà)機(jī)已經(jīng)非常普及，SIP話(huà)機(jī)的DSP支持了多種編碼的壓縮。

　　資源來(lái)自于互聯(lián)網(wǎng)

　　有時(shí)，編碼一旦被選定以后，編碼不能輕易被修改。以下這個(gè)示例演示了通過(guò)初始化的offer/answer交互創(chuàng)建會(huì)話(huà)的流程，然后馬上通過(guò)第二個(gè)offer選擇編碼組鎖定需要的編碼。從Alice發(fā)送到Bob的初始o(jì)ffer中指示單媒體流可使用三種編碼，這三種編碼都是DSP中支持的編碼。因?yàn)锳lice還沒(méi)有收到媒體流，編碼鎖定以后才能發(fā)送媒體流，因此，這里的媒體流標(biāo)識(shí)為inactive狀態(tài)：

　　v=0

　　o=alice 2890844526 2890844526 IN IP4 host.anywhere.com

　　s=

　　c=IN IP4 host.anywhere.com

　　t=0 0

　　m=audio 62986 RTP/AVP 0 4 18

　　a=rtpmap:0 PCMU/8000

　　a=rtpmap:4 G723/8000

　　a=rtpmap:18 G729/8000

　　a=inactive

　　v=0

　　o=bob 2890844730 2890844731 IN IP4 host.example.com

　　s=

　　c=IN IP4 host.example.com

　　t=0 0

　　m=audio 54344 RTP/AVP 0 4

　　a=rtpmap:0 PCMU/8000

　　a=rtpmap:4 G723/8000

　　a=inactive

　　Alice收到Bob的answer以后，從收到的兩種編碼中選擇了其中一種編碼G.723，通過(guò)一個(gè)更新的offer消息，并且標(biāo)識(shí)其媒體流的媒體指向是sendrecv狀態(tài)。

　　v=0

　　o=alice 2890844526 2890844527 IN IP4 host.anywhere.com

　　s=

　　c=IN IP4 host.anywhere.com

　　t=0 0

　　m=audio 62986 RTP/AVP 4

　　a=rtpmap:4 G723/8000

　　a=sendrecv

　　Bob收到更新的offer以后，接受其編碼G.723, 發(fā)送answer給Alice。

　　v=0

　　o=bob 2890844730 2890844732 IN IP4 host.example.com

　　s=

　　c=IN IP4 host.example.com

　　t=0 0

　　m=audio 54344 RTP/AVP 4

　　a=rtpmap:4 G723/8000

　　a=sendrecv

　　如果Bob這里只能支持N選一（one-of-N codecs）的編碼方式的話(huà)，Bob將會(huì)從offer中提供的編碼中選擇其中一個(gè)可用編碼，然后把選擇的編碼通過(guò)answer發(fā)送到對(duì)端。這種情況下，Alice將會(huì)重新發(fā)起一個(gè)re-INVITE請(qǐng)求啟用此最后協(xié)商的編碼來(lái)傳輸媒體流。以上筆者介紹的是在第一次初始化offer中使用了"a=inactive"。對(duì)于在第一次交互中使用"a=inactive"指向的方式來(lái)說(shuō)，另外一種處理方式是Alice可以列出所有的編碼，只要她從Bob收到媒體流以后，然后馬上生成一個(gè)更新的offer消息，在更新的offer中鎖定一種剛才從Bob收到的媒體格式，使用其鎖定的編碼格式來(lái)傳輸媒體流。當(dāng)然，如果Bob這里只能支持N選一（one-of-N codecs）的編碼方式的話(huà)，他的answer中將會(huì)包含一種編碼格式，這種情況下，Alice也不需要發(fā)起一個(gè)re-INVITE請(qǐng)求鎖定編碼。當(dāng)然，如果雙方的編碼協(xié)商不能成功的話(huà)，需要在B2BUA上進(jìn)行編碼轉(zhuǎn)換的處理。關(guān)于編碼轉(zhuǎn)換的問(wèn)題，筆者在歷史文檔中有深入的討論，這里不再重復(fù)。讀者可以參考：

　　以上是一個(gè)關(guān)于帶物理DSP的SIP話(huà)機(jī)簡(jiǎn)單編碼協(xié)商流程。除了SIP終端之間的協(xié)商以外，我們?cè)谏�產(chǎn)環(huán)境中還會(huì)看到網(wǎng)關(guān)產(chǎn)品的編碼協(xié)商處理的使用場(chǎng)景�，F(xiàn)在，我們通過(guò)一個(gè)語(yǔ)音網(wǎng)關(guān)的編碼協(xié)商的示例來(lái)說(shuō)明編碼協(xié)商是如何進(jìn)行的。再次說(shuō)明，這里的示例僅是某個(gè)廠(chǎng)家的網(wǎng)關(guān)的簡(jiǎn)單示例（多個(gè)“m=”行支持），可能和其他廠(chǎng)家的處理機(jī)制在細(xì)節(jié)上有所差別，但是原理基本上都是一致的（遵從RFC 3264規(guī)范）。示例中，網(wǎng)關(guān)通過(guò)offer/answer交互模式，通過(guò)第一個(gè)“m=”行和端口設(shè)置（m=0）接受了所需要的媒體格式，拒絕了不能支持的媒體。注意，這里的編碼優(yōu)先級(jí)不會(huì)影響offer中編碼的選擇，僅影響answer中編碼選擇方式。

　　圖例來(lái)自于互聯(lián)網(wǎng)

　　語(yǔ)音呼叫環(huán)境中，SIP INVITE進(jìn)入到網(wǎng)關(guān)以后的offer和網(wǎng)關(guān)返回的answer消息對(duì)比：

Default Codec = G.711 ulaw m=audio 38400 RTP/AVP 0 m=audio 49500 RTP/AVP 8 m=audio 6000 RTP/AVP 0 // 接受 m=audio 0 RTP/AVP 8 // 拒絕

　　offer中提供了兩種編碼的支持，但是網(wǎng)關(guān)發(fā)送到answer接受了payload type為0的媒體格式（在answer中是第一個(gè)編碼），拒絕了payload是8的媒體，設(shè)置其端口為0。

　　除了以上協(xié)商的策略以外，可能還有一個(gè)需要問(wèn)題需要讀者要注意，那就是呼叫流程中“early offer”和“late offer”的問(wèn)題，因?yàn)樵贐2BUA中涉及了編碼協(xié)商的機(jī)制和編碼轉(zhuǎn)換的問(wèn)題，它們會(huì)影響到編碼協(xié)商的最終結(jié)果。最早的SIP應(yīng)用場(chǎng)景中很多是使用early offer模式，但是隨著網(wǎng)絡(luò)架構(gòu)和網(wǎng)絡(luò)環(huán)境越來(lái)越復(fù)雜，更多的性能優(yōu)化需要調(diào)整編碼能力或者帶寬/QoS等業(yè)務(wù)要求，所以，在SIP網(wǎng)絡(luò)中使用later offer的場(chǎng)景也逐漸多了。一些讀者可能沒(méi)有注意這兩個(gè)概念的不同或比較迷惑這兩個(gè)概念。首先，討論簡(jiǎn)單說(shuō)明一下什么是“early offer”和“late/delayed offer”。其實(shí)，這兩個(gè)概念也沒(méi)有太難理解的地方，顧名思義，early offer就是在INVITE請(qǐng)求中包含SDP消息，later offer就是在后續(xù)的ACK中包含SDP消息。例如，如果一個(gè)UAC發(fā)起一個(gè)INVITE請(qǐng)求，并且在INVITE（offer消息）做包括了SDP消息，SDP消息中指示了UAC所支持的媒體格式，例如通常使用的G.711和G.723等編碼。請(qǐng)求的接收方收到SDP消息后解析編碼，然后根據(jù)所支持的編碼決定接收方UAS使用何種編碼來(lái)進(jìn)行媒體傳輸。注意，UAC（被呼叫方）首先看到的是UAS（呼叫方）在SDP中的編碼。這種情況下，相當(dāng)于UAC已經(jīng)把可以選擇的編碼提供給了被呼叫方，被呼叫方?jīng)]有什么選擇的余地，它只能根據(jù)UAS提供的編碼進(jìn)行選擇。所以，其實(shí)在early offer中，UAS具有更多的自主權(quán)，而UAC只能從編碼中被動(dòng)選擇需要的編碼。當(dāng)然，其優(yōu)點(diǎn)是UAS降低了編碼編碼處理的的復(fù)雜度。

　　early offer 示例（INVITE包含SDP）

　　前面筆者討論了early offer，呼叫方首先提供了一種選擇權(quán)讓對(duì)方來(lái)選擇。和early offer相反的是later offer。從字面意思也可以看到，early或later僅是一個(gè)offer SDP的時(shí)間問(wèn)題。Later offer更多的offer消息的選擇權(quán)則是由被呼叫方晚一點(diǎn)提供。呼叫方在INVITE呼叫請(qǐng)求發(fā)送時(shí)，沒(méi)有包含SDP消息，同時(shí)雙方也進(jìn)行正常的INVITE流程處理，被呼叫方返回一個(gè)臨時(shí)響應(yīng)，例如，發(fā)送 180振鈴（但是，被呼叫方此時(shí)還沒(méi)有準(zhǔn)備好或意識(shí)到使用何種編碼）或者183（帶SDP，下面討論此問(wèn)題），緊接著發(fā)送 200 ok（帶SDP消息，這時(shí)開(kāi)始發(fā)送offer消息/later offer）。呼叫方收到 200 ok 以后，結(jié)合其offer中的SDP消息，然后返回ACK（包含SDP消息體）。實(shí)際上，呼叫方最終決定使用何種編碼。

　　later offer（ACK中包含）

　　在later offer中的場(chǎng)景中，有兩個(gè)比較重要的問(wèn)題可能會(huì)影響呼叫。有時(shí)，發(fā)送了200 ok最終響應(yīng)的設(shè)備會(huì)馬上發(fā)送媒體流，此時(shí)對(duì)端可能還沒(méi)有收到 200 ok（包括SDP），它們之間的會(huì)話(huà)也根本沒(méi)有創(chuàng)建，因此可能出現(xiàn)語(yǔ)音丟失的問(wèn)題，語(yǔ)音丟失的長(zhǎng)度可能完全取決于雙方最后協(xié)商的時(shí)間。所以，有時(shí)我們經(jīng)常遇到，通話(huà)開(kāi)始的前幾秒可能雙方都聽(tīng)不到對(duì)方的聲音，或者播放IVR時(shí)，IVR語(yǔ)音的前幾秒語(yǔ)音丟失。另外一個(gè)問(wèn)題就是在被呼叫方發(fā)送臨時(shí)響應(yīng)時(shí)，它沒(méi)有發(fā)送180 振鈴，但是有時(shí)發(fā)送的是183（帶SDP），這樣的臨時(shí)響應(yīng)攜帶了媒體。因?yàn)榇藭r(shí)此刻，沒(méi)有協(xié)商流程還沒(méi)有完成也沒(méi)有協(xié)商成功，呼叫方的媒體端口或者地址還沒(méi)有開(kāi)啟，因此，SDP中攜帶的媒體流可能就會(huì)在中途丟失，例如，聽(tīng)不到回鈴音，彩鈴或者其他的語(yǔ)音業(yè)務(wù)播放的媒體。這些問(wèn)題可能需要經(jīng)過(guò)一些B2BUA的處理（在Asterisk或者FreeSWITCH都針對(duì)兩種offer有相關(guān)的具體配置。），有時(shí)需要PRACK的支持，在媒體服務(wù)器端針對(duì)性地進(jìn)行設(shè)置（增加progress 處理，等待，或者answer處理等）或者在其呼叫路徑中增加一個(gè)SBC來(lái)處理later offer帶來(lái)的這些問(wèn)題。

　　參考資料：

　　https://tools.ietf.org/id/draft-ietf-mmusic-ice-sip-sdp-14.html

　　https://tools.ietf.org/html/draft-ietf-rmcat-cc-codec-interactions-00

　　https://www.swisscom.ch/content/dam/swisscom/en/about/company/network/all-ip/documents

　　https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation

　　https://lists.cs.columbia.edu/pipermail/sip-implementors/2018-December/031167.html

　　在接下來(lái)的章節(jié)中，筆者將繼續(xù)討論SDP offer/answer交互模式中NAT處理以及ICE。