因為更新offer的內容比較龐雜，為了讓讀者有一個(gè)比較好的閱讀體驗，筆者計劃將上述內容分為三個(gè)部分來(lái)介紹。本文章介紹第一個(gè)部分的內容（生成后續offer），在以后的文章中分別介紹第二部分和第三部分的內容。
本文章主要涵蓋關(guān)于生成后續offer的內容：
- 整體部署場(chǎng)景討論（ICE 重新啟動(dòng)，移除媒體流，增加媒體流）
- 全場(chǎng)景部署討論：ICE運行時(shí)現存媒體流處理和ICE完成后現存媒體流處理。
- 輕量級場(chǎng)景部署討論：ICE運行時(shí)現存媒體流處理和ICE完成后現存媒體流處理。
在討論后續offer/answer交互模式時(shí)，首先需要關(guān)注的是關(guān)于如何生成更新的offer消息。在生成更新offer消息中，RFC5245分別規定了兩種常見(jiàn)的處理流程（全場(chǎng)景部署場(chǎng)景和輕量級部署場(chǎng)景）。接下來(lái)，筆者會(huì )首先對整體部署場(chǎng)景進(jìn)行討論，然后分別對兩種部署場(chǎng)景中關(guān)于不同ICE運行狀態(tài)環(huán)境中現存媒體流的處理進(jìn)行討論。
注意：關(guān)于ICE重新啟動(dòng)的細節，RFC5245和RFC8445規范有非常某些區別，筆者這里以RFC5245的規范作為討論基礎。如果對最新的規范有興趣的話(huà)，可以查閱RFC8445的細節。
1整體部署場(chǎng)景討論
在討論后續offer/answer交互模式時(shí)，首先需要關(guān)注的是關(guān)于如何生成更新的offer消息。在生成更新offer消息中，針對agent，RFC5245分別規定了兩種常見(jiàn)的處理流程（全場(chǎng)景部署場(chǎng)景和輕量級部署場(chǎng)景）。在介紹這兩種部署場(chǎng)景的處理流程之前，我們首先介紹三個(gè)和整體部署場(chǎng)景相關(guān)的內容。第一個(gè)是關(guān)于重新啟動(dòng)ICE流程的討論。
Agent可以對現存的媒體流重新啟動(dòng)ICE處理流程。重新啟動(dòng)ICE處理流程會(huì )導致前面的ICE處理流程被刷新，并且還要重新啟動(dòng)檢查流程。注意，重新啟動(dòng)ICE處理流程和重新創(chuàng )建一個(gè)新會(huì )話(huà)之間有不同之處，在重新啟動(dòng)ICE處理流程的過(guò)程中，媒體流仍然會(huì )被發(fā)送到以前的有效配對目的地。對于一個(gè)媒體流來(lái)說(shuō)，如果有以下兩種情況可能發(fā)生的話(huà)，agent必須重新啟動(dòng)ICE流程：
已經(jīng)生成了offer，此offer的目的是為了修改媒體流目的地。簡(jiǎn)單來(lái)說(shuō)，就是agent想生成一個(gè)更新的offer消息（ICE沒(méi)有使用這個(gè)offer），這樣的結果是為媒體構件目的地生成一個(gè)新的值。
Agent正在修改其部署級別。正在情況一般發(fā)生在第三方呼叫控制的環(huán)境中。對象實(shí)體正在使用的信令不是實(shí)體接收媒體的信令，并且這個(gè)實(shí)體已經(jīng)從媒體 mid-session的目的地修改為另外一個(gè)實(shí)體，這個(gè)實(shí)體具有不同的ICE部署環(huán)境。
另外一些規則的修改也會(huì )引起ICE重新啟動(dòng)，SDP中的c行中IP地址修改為0.0.0.0會(huì )引起ICE重新啟動(dòng)。因此，如果需要支持呼叫等待業(yè)務(wù)功能的話(huà)，ICE部署中則不能使用以上機制，它必須使用a=inactive和a=sendonly設置。因為這里涉及了IPv6的網(wǎng)絡(luò )場(chǎng)景，舊規范RFC3264已經(jīng)做了更新，關(guān)于此要求最新細節，建議讀者可以參考RFC6157-4.1章節的介紹。如果agent要為媒體流重新啟動(dòng)ICE流程的話(huà)，agent必須在offer消息中修改認證用戶(hù)需要的兩個(gè)屬性ice-pwd和ice- ufrag。注意，RFC5245規范也允許agent在offer中使用會(huì )話(huà)級的屬性設置，僅為在后續的offer中作為一個(gè)媒體級屬性提供同樣的ice-pwd或ice- ufrag。這樣的操作不會(huì )修改密碼，不會(huì )修改其呈現方式，也不會(huì )引起ICE重新啟動(dòng)。Agent在SDP中設置了多個(gè)其他的屬性，這些屬性在包含在初始化的offer中。針對此媒體流，在接下來(lái)的更新offer的處理流程中，候選地址組會(huì )根據實(shí)際情況，可能會(huì )包括其中一些參數或者沒(méi)有包含任何參數，或者前面的候選地址，并且可能包括全新采集的候選地址組。候選地址采集的采集通過(guò)采集候選地址來(lái)執行（關(guān)于候選地址場(chǎng)景請參考歷史文章）。
根據RFC3264的規范規定，如果agent需要移除媒體的話(huà)，它可以設置其端口為0。這個(gè)規則在這里也適用。除了agent設置端口為0以外，針對要移除的媒體流，它一定不能包含任何候選地址屬性，并且不應該包括任何ICE相關(guān)的屬性設置。具體的ICE相關(guān)屬性，參考如下示例：
如果agent想增加一個(gè)新的媒體流的話(huà)，它需要在SDP中為此媒體流設置相關(guān)的域值。這些SDP中的相關(guān)域值設置需要參考初始化offer中關(guān)于SDP解碼中的設置。Agent修改了這些媒體流的設置后，ICE處理流程就會(huì )開(kāi)始發(fā)送媒體流。
以上內容介紹了整體部署環(huán)境中關(guān)于ICE重新啟動(dòng)，移除媒體流和刪除媒體流的處理流程。接下來(lái)，我們將首先針對全場(chǎng)景部署環(huán)境中處理流程進(jìn)行說(shuō)明。
2全場(chǎng)景部署環(huán)境處理流程
這個(gè)章節將對在全場(chǎng)景部署環(huán)境中，在不同ICE運行狀態(tài)下對現存媒體流進(jìn)行的處理做詳細說(shuō)明。這里要注意這三個(gè)參數環(huán)境，用戶(hù)名稱(chēng)（ice- ufrag），密碼（ ice-pwd）和部署級別，前面使用的這三個(gè)條件沒(méi)有發(fā)生改變。如果agent需要修改其中一個(gè)參數條件，ICE就需要重新啟動(dòng)。
如果agent生成了一個(gè)更新的offer，在更新offer中包括了一個(gè)以前已創(chuàng )建的媒體流，并且ICE檢查也在運行狀態(tài)時(shí)，agent需要根據以下流程執行。針對此媒體流，此agent必須為所有本地候選地址包括候選屬性。在SDP標識的候選地址的屬性，例如，priority，foundation，type和相關(guān)傳輸地址都應該保持不變。候選地址中基礎的確認信息，例如，IP 地址，port和傳輸協(xié)議一定不能發(fā)生變化（如果其中一個(gè)發(fā)生變化，則說(shuō)明是一個(gè)新的候選地址）。component ID和以前的component ID保持一致。Agent可以包括以前offer中沒(méi)有生成的其他候選地址，但是，自從上一次offer/answer交互以后，對agent已經(jīng)采集的候選地址來(lái)說(shuō)，需要包括一個(gè)peer reflexive candidates。針對媒體來(lái)說(shuō)，就像在初始offer中的一樣，肯定有一組候選屬性可以匹配默認目的地地址，agent可以為此媒體修改默認目的地地址。
以上是ICE在運行狀態(tài)時(shí)，agent更新offer需要執行的流程。除了ICE處于正在執行狀態(tài)以外，ICE檢查也可能是完成狀態(tài)。如果agent生成了一個(gè)更新的offer，在更新offer中包括了一個(gè)以前已創(chuàng )建的媒體流，并且ICE檢查在完成狀態(tài)時(shí)，agent需要根據以下流程執行。針對媒體的默認目的地地址（例如，媒體流的m行和c行中的IP地址和端口值）必須是本地候選地址，這個(gè)本地候選地址來(lái)自于對每個(gè)媒體構件的有效列表最高優(yōu)先級推薦配對。通過(guò)這樣的處理方式可以“修復”目的地地址，讓默認媒體的目的地地址等于ICE為此媒體的已選地址。Agent必須包含一些候選地址的候選屬性，這些候選屬性匹配了媒體流中每個(gè)構件的默認目的地地址，并且agent一定不能包含其他候選地址。另外，如果agent是一個(gè)被控方agent的話(huà)，它必須為每個(gè)媒體流（這些媒體流的檢查列表是在ICE完成狀態(tài)）包含a=remote-candidates屬性。這個(gè)屬性設置中包含遠端候選地址，這些地址來(lái)自于此媒體流的每個(gè)構件所支持的有效列表中的最高優(yōu)先級配對取值。這里可能存在一種極端情況，這種情況需要盡量避免。被控方agent選擇了它的配對，但是更新offer對主控方agent執行了一個(gè)序亂的連接檢查。這種情況下，對端agent可能不知道哪個(gè)配對是有效配對。因此，在更新offer使用a=remote-candidates屬性避免更新offer和STUN檢查協(xié)議之間因為請求/響應消息丟失出現的這種極端情況。注意，這種極端情況的處理機制討論僅在RFC5245的規范中有規定，但是在RFC8445中取消了這種處理來(lái)自。相對于RFC5245，RFC8445針對ICE重新啟動(dòng)做了大幅簡(jiǎn)化處理。
a=remote-candidates 避免配對序亂處理（RFC5245）
3輕量級部署環(huán)境處理流程
這個(gè)部分的討論和前面的討論應用，筆者也會(huì )分別針對兩種ICE運行狀態(tài)下的輕量級部署環(huán)境的處理流程進(jìn)行介紹。
首先說(shuō)明一下輕量級部署中針對現存媒體流，ICE流程處于運行狀態(tài)時(shí)的處理流程。輕量級部署必須在任何后續的offer中的a=candidate為每個(gè)媒體流的每個(gè)構件的包含所有的候選地址。候選地址的構建和初始化offer中關(guān)于候選地址的構建的流程完全相同。具體的構建流程在前面的歷史文章中有專(zhuān)門(mén)介紹，讀者可以查閱歷史文檔。輕量級部署中一定不能在后續offer中再增加其他的主機候選地址。如果agent想增加一個(gè)新的主機候選地址的話(huà)，agent必須重新啟動(dòng)ICE處理流程。在后續offer中的用戶(hù)名稱(chēng)（ice- ufrag），密碼（ ice-pwd）和部署級別應該和前面offer中的屬性保持一致，如果以上三種參數后續offer中發(fā)生修改，agent則必須為此媒體流重新啟動(dòng)ICE處理流程。
針對媒體流來(lái)說(shuō)，如果ICE處理狀態(tài)處于完成狀態(tài)，此媒體流的默認目的地地址必須設置為此媒體流構件的候選配對（在有效列表中）的遠端候選地址。對輕量級部署來(lái)說(shuō)，總是支持一個(gè)在有效列表中的單候選配對。另外，agent必須為每個(gè)默認目的地包含一個(gè)候選地址屬性。
如果agent是一個(gè)被控方agent的話(huà)（僅發(fā)生在雙方都是輕量級部署的agent），此agent必須為每個(gè)媒體流包含一個(gè)a=remote-candidates。a=remote-candidates中包含遠端候選地址，這個(gè)遠端候選地址來(lái)自于有效列表中的候選配對（每個(gè)媒體流的每個(gè)構件有一對候選配對）。
在接下來(lái)的章節中，筆者將繼續介紹針對更新offer中對端agent接收offer和生成answer的處理流程。
參考資料：
https://www.rfc-editor.org/rfc/rfc3264
https://www.rfc-editor.org/rfc/rfc6336
https://www.rfc-editor.org/rfc/rfc8445
關(guān)注微信公眾號：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享
最新Asterisk完整中文用戶(hù)手冊詳解及免費slack支持：www.asterisk.org.cn
Freepbx/FreeSBC技術(shù)文檔： www.freepbx.org.cn
融合通信/IPPBX商業(yè)解決方案：www.hiastar.com
如何使用FreeSBC，qq技術(shù)分享群：334023047
