因?yàn)楦�新offer的內(nèi)容比較龐雜，為了讓讀者有一個(gè)比較好的閱讀體驗(yàn)，筆者計(jì)劃將上述內(nèi)容分為三個(gè)部分來介紹。本文章介紹第一個(gè)部分的內(nèi)容（生成后續(xù)offer），在以后的文章中分別介紹第二部分和第三部分的內(nèi)容。

　　本文章主要涵蓋關(guān)于生成后續(xù)offer的內(nèi)容：

　　在討論后續(xù)offer/answer交互模式時(shí)，首先需要關(guān)注的是關(guān)于如何生成更新的offer消息。在生成更新offer消息中，RFC5245分別規(guī)定了兩種常見的處理流程（全場(chǎng)景部署場(chǎng)景和輕量級(jí)部署場(chǎng)景）。接下來，筆者會(huì)首先對(duì)整體部署場(chǎng)景進(jìn)行討論，然后分別對(duì)兩種部署場(chǎng)景中關(guān)于不同ICE運(yùn)行狀態(tài)環(huán)境中現(xiàn)存媒體流的處理進(jìn)行討論。

　　注意：關(guān)于ICE重新啟動(dòng)的細(xì)節(jié)，RFC5245和RFC8445規(guī)范有非常某些區(qū)別，筆者這里以RFC5245的規(guī)范作為討論基礎(chǔ)。如果對(duì)最新的規(guī)范有興趣的話，可以查閱RFC8445的細(xì)節(jié)。

　　在討論后續(xù)offer/answer交互模式時(shí)，首先需要關(guān)注的是關(guān)于如何生成更新的offer消息。在生成更新offer消息中，針對(duì)agent，RFC5245分別規(guī)定了兩種常見的處理流程（全場(chǎng)景部署場(chǎng)景和輕量級(jí)部署場(chǎng)景）。在介紹這兩種部署場(chǎng)景的處理流程之前，我們首先介紹三個(gè)和整體部署場(chǎng)景相關(guān)的內(nèi)容。第一個(gè)是關(guān)于重新啟動(dòng)ICE流程的討論。

　　Agent可以對(duì)現(xiàn)存的媒體流重新啟動(dòng)ICE處理流程。重新啟動(dòng)ICE處理流程會(huì)導(dǎo)致前面的ICE處理流程被刷新，并且還要重新啟動(dòng)檢查流程。注意，重新啟動(dòng)ICE處理流程和重新創(chuàng)建一個(gè)新會(huì)話之間有不同之處，在重新啟動(dòng)ICE處理流程的過程中，媒體流仍然會(huì)被發(fā)送到以前的有效配對(duì)目的地。對(duì)于一個(gè)媒體流來說，如果有以下兩種情況可能發(fā)生的話，agent必須重新啟動(dòng)ICE流程：

　　已經(jīng)生成了offer，此offer的目的是為了修改媒體流目的地。簡(jiǎn)單來說，就是agent想生成一個(gè)更新的offer消息（ICE沒有使用這個(gè)offer），這樣的結(jié)果是為媒體構(gòu)件目的地生成一個(gè)新的值。

　　Agent正在修改其部署級(jí)別。正在情況一般發(fā)生在第三方呼叫控制的環(huán)境中。對(duì)象實(shí)體正在使用的信令不是實(shí)體接收媒體的信令，并且這個(gè)實(shí)體已經(jīng)從媒體 mid-session的目的地修改為另外一個(gè)實(shí)體，這個(gè)實(shí)體具有不同的ICE部署環(huán)境。

　　另外一些規(guī)則的修改也會(huì)引起ICE重新啟動(dòng)，SDP中的c行中IP地址修改為0.0.0.0會(huì)引起ICE重新啟動(dòng)。因此，如果需要支持呼叫等待業(yè)務(wù)功能的話，ICE部署中則不能使用以上機(jī)制，它必須使用a=inactive和a=sendonly設(shè)置。因?yàn)檫@里涉及了IPv6的網(wǎng)絡(luò)場(chǎng)景，舊規(guī)范RFC3264已經(jīng)做了更新，關(guān)于此要求最新細(xì)節(jié)，建議讀者可以參考RFC6157-4.1章節(jié)的介紹。如果agent要為媒體流重新啟動(dòng)ICE流程的話，agent必須在offer消息中修改認(rèn)證用戶需要的兩個(gè)屬性ice-pwd和ice- ufrag。注意，RFC5245規(guī)范也允許agent在offer中使用會(huì)話級(jí)的屬性設(shè)置，僅為在后續(xù)的offer中作為一個(gè)媒體級(jí)屬性提供同樣的ice-pwd或ice- ufrag。這樣的操作不會(huì)修改密碼，不會(huì)修改其呈現(xiàn)方式，也不會(huì)引起ICE重新啟動(dòng)。Agent在SDP中設(shè)置了多個(gè)其他的屬性，這些屬性在包含在初始化的offer中。針對(duì)此媒體流，在接下來的更新offer的處理流程中，候選地址組會(huì)根據(jù)實(shí)際情況，可能會(huì)包括其中一些參數(shù)或者沒有包含任何參數(shù)，或者前面的候選地址，并且可能包括全新采集的候選地址組。候選地址采集的采集通過采集候選地址來執(zhí)行（關(guān)于候選地址場(chǎng)景請(qǐng)參考?xì)v史文章）。

　　根據(jù)RFC3264的規(guī)范規(guī)定，如果agent需要移除媒體的話，它可以設(shè)置其端口為0。這個(gè)規(guī)則在這里也適用。除了agent設(shè)置端口為0以外，針對(duì)要移除的媒體流，它一定不能包含任何候選地址屬性，并且不應(yīng)該包括任何ICE相關(guān)的屬性設(shè)置。具體的ICE相關(guān)屬性，參考如下示例：

　　如果agent想增加一個(gè)新的媒體流的話，它需要在SDP中為此媒體流設(shè)置相關(guān)的域值。這些SDP中的相關(guān)域值設(shè)置需要參考初始化offer中關(guān)于SDP解碼中的設(shè)置。Agent修改了這些媒體流的設(shè)置后，ICE處理流程就會(huì)開始發(fā)送媒體流。

　　以上內(nèi)容介紹了整體部署環(huán)境中關(guān)于ICE重新啟動(dòng)，移除媒體流和刪除媒體流的處理流程。接下來，我們將首先針對(duì)全場(chǎng)景部署環(huán)境中處理流程進(jìn)行說明。

　　這個(gè)章節(jié)將對(duì)在全場(chǎng)景部署環(huán)境中，在不同ICE運(yùn)行狀態(tài)下對(duì)現(xiàn)存媒體流進(jìn)行的處理做詳細(xì)說明。這里要注意這三個(gè)參數(shù)環(huán)境，用戶名稱（ice- ufrag），密碼（ ice-pwd）和部署級(jí)別，前面使用的這三個(gè)條件沒有發(fā)生改變。如果agent需要修改其中一個(gè)參數(shù)條件，ICE就需要重新啟動(dòng)。

　　如果agent生成了一個(gè)更新的offer，在更新offer中包括了一個(gè)以前已創(chuàng)建的媒體流，并且ICE檢查也在運(yùn)行狀態(tài)時(shí)，agent需要根據(jù)以下流程執(zhí)行。針對(duì)此媒體流，此agent必須為所有本地候選地址包括候選屬性。在SDP標(biāo)識(shí)的候選地址的屬性，例如，priority，foundation，type和相關(guān)傳輸?shù)刂范紤?yīng)該保持不變。候選地址中基礎(chǔ)的確認(rèn)信息，例如，IP 地址，port和傳輸協(xié)議一定不能發(fā)生變化（如果其中一個(gè)發(fā)生變化，則說明是一個(gè)新的候選地址）。component ID和以前的component ID保持一致。Agent可以包括以前offer中沒有生成的其他候選地址，但是，自從上一次offer/answer交互以后，對(duì)agent已經(jīng)采集的候選地址來說，需要包括一個(gè)peer reflexive candidates。針對(duì)媒體來說，就像在初始o(jì)ffer中的一樣，肯定有一組候選屬性可以匹配默認(rèn)目的地地址，agent可以為此媒體修改默認(rèn)目的地地址。

　　以上是ICE在運(yùn)行狀態(tài)時(shí)，agent更新offer需要執(zhí)行的流程。除了ICE處于正在執(zhí)行狀態(tài)以外，ICE檢查也可能是完成狀態(tài)。如果agent生成了一個(gè)更新的offer，在更新offer中包括了一個(gè)以前已創(chuàng)建的媒體流，并且ICE檢查在完成狀態(tài)時(shí)，agent需要根據(jù)以下流程執(zhí)行。針對(duì)媒體的默認(rèn)目的地地址（例如，媒體流的m行和c行中的IP地址和端口值）必須是本地候選地址，這個(gè)本地候選地址來自于對(duì)每個(gè)媒體構(gòu)件的有效列表最高優(yōu)先級(jí)推薦配對(duì)。通過這樣的處理方式可以“修復(fù)”目的地地址，讓默認(rèn)媒體的目的地地址等于ICE為此媒體的已選地址。Agent必須包含一些候選地址的候選屬性，這些候選屬性匹配了媒體流中每個(gè)構(gòu)件的默認(rèn)目的地地址，并且agent一定不能包含其他候選地址。另外，如果agent是一個(gè)被控方agent的話，它必須為每個(gè)媒體流（這些媒體流的檢查列表是在ICE完成狀態(tài)）包含a=remote-candidates屬性。這個(gè)屬性設(shè)置中包含遠(yuǎn)端候選地址，這些地址來自于此媒體流的每個(gè)構(gòu)件所支持的有效列表中的最高優(yōu)先級(jí)配對(duì)取值。這里可能存在一種極端情況，這種情況需要盡量避免。被控方agent選擇了它的配對(duì)，但是更新offer對(duì)主控方agent執(zhí)行了一個(gè)序亂的連接檢查。這種情況下，對(duì)端agent可能不知道哪個(gè)配對(duì)是有效配對(duì)。因此，在更新offer使用a=remote-candidates屬性避免更新offer和STUN檢查協(xié)議之間因?yàn)檎?qǐng)求/響應(yīng)消息丟失出現(xiàn)的這種極端情況。注意，這種極端情況的處理機(jī)制討論僅在RFC5245的規(guī)范中有規(guī)定，但是在RFC8445中取消了這種處理來自。相對(duì)于RFC5245，RFC8445針對(duì)ICE重新啟動(dòng)做了大幅簡(jiǎn)化處理。

　　a=remote-candidates 避免配對(duì)序亂處理（RFC5245）

　　這個(gè)部分的討論和前面的討論應(yīng)用，筆者也會(huì)分別針對(duì)兩種ICE運(yùn)行狀態(tài)下的輕量級(jí)部署環(huán)境的處理流程進(jìn)行介紹。

　　首先說明一下輕量級(jí)部署中針對(duì)現(xiàn)存媒體流，ICE流程處于運(yùn)行狀態(tài)時(shí)的處理流程。輕量級(jí)部署必須在任何后續(xù)的offer中的a=candidate為每個(gè)媒體流的每個(gè)構(gòu)件的包含所有的候選地址。候選地址的構(gòu)建和初始化offer中關(guān)于候選地址的構(gòu)建的流程完全相同。具體的構(gòu)建流程在前面的歷史文章中有專門介紹，讀者可以查閱歷史文檔。輕量級(jí)部署中一定不能在后續(xù)offer中再增加其他的主機(jī)候選地址。如果agent想增加一個(gè)新的主機(jī)候選地址的話，agent必須重新啟動(dòng)ICE處理流程。在后續(xù)offer中的用戶名稱（ice- ufrag），密碼（ ice-pwd）和部署級(jí)別應(yīng)該和前面offer中的屬性保持一致，如果以上三種參數(shù)后續(xù)offer中發(fā)生修改，agent則必須為此媒體流重新啟動(dòng)ICE處理流程。

　　針對(duì)媒體流來說，如果ICE處理狀態(tài)處于完成狀態(tài)，此媒體流的默認(rèn)目的地地址必須設(shè)置為此媒體流構(gòu)件的候選配對(duì)（在有效列表中）的遠(yuǎn)端候選地址。對(duì)輕量級(jí)部署來說，總是支持一個(gè)在有效列表中的單候選配對(duì)。另外，agent必須為每個(gè)默認(rèn)目的地包含一個(gè)候選地址屬性。

　　如果agent是一個(gè)被控方agent的話（僅發(fā)生在雙方都是輕量級(jí)部署的agent），此agent必須為每個(gè)媒體流包含一個(gè)a=remote-candidates。a=remote-candidates中包含遠(yuǎn)端候選地址，這個(gè)遠(yuǎn)端候選地址來自于有效列表中的候選配對(duì)（每個(gè)媒體流的每個(gè)構(gòu)件有一對(duì)候選配對(duì)）。

　　在接下來的章節(jié)中，筆者將繼續(xù)介紹針對(duì)更新offer中對(duì)端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)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的Asterisk行業(yè)分享

　　最新Asterisk完整中文用戶手冊(cè)詳解及免費(fèi)slack支持：www.asterisk.org.cn

　　Freepbx/FreeSBC技術(shù)文檔： www.freepbx.org.cn

　　融合通信/IPPBX商業(yè)解決方案：www.hiastar.com

　　如何使用FreeSBC，qq技術(shù)分享群：334023047