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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　在接下來的章節(jié)中，筆者將繼續(xù)介紹針對更新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，獲得有價值的Asterisk行業(yè)分享

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

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

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

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