整體部署場景討論（檢測ICE重新啟動，移除媒體流，增加媒體流）

　　全場景部署討論：無remote-candidates屬性狀態(tài)下，ICE運行時現(xiàn)存媒體流處理和ICE完成后現(xiàn)存媒體流處理，帶remote-candidates現(xiàn)存媒體流處理。

　　輕量級場景部署討論：ICE運行時現(xiàn)存媒體流處理和ICE完成后現(xiàn)存媒體流處理。

　　讀者注意，在這里討論的offer/answer已經(jīng)涉及到了后續(xù)offer的內(nèi)容，也就是更新的offer，所以有時會和初始o(jì)ffer時的一些屬性進(jìn)行對比處理，讀者一定不要迷惑。

　　當(dāng)agent在現(xiàn)存會話中收到后續(xù)offer時，無論前面的offer/answer交互驗證是否成功，agent必須重新檢查一次驗證ICE支持能力（前面的文章中介紹過接收初始o(jì)ffer關(guān)于ICE能力支持驗證流程）。雖然，前面offer/answer交互可能導(dǎo)致ICE不能使用，不過，這種處理結(jié)果可以作為后續(xù)offer/answer交互的結(jié)果使用。和上一篇文章中所討論的應(yīng)用，agent接收offer時，對于整體部署場景來說，仍然需要執(zhí)行常規(guī)的三個步驟的處理：檢測ICE重新啟動，添加媒體流處理，移除媒體流處理�，F(xiàn)在，我們分別加以介紹。

　　用戶屬性發(fā)生了修改，agent需要重新檢測并且重新啟動ICE。具體來說，agent和前面收到的SDP中屬性對比，如果agent在收到的更新offer消息中包含了一個已修改的屬性（可能是a=ice-ufrag 或者a=ice-pwd），針對此媒體流，agent需要重新啟動ICE。如果所有的媒體流需要重新啟動的話，所有ICE也需要重新啟動。如果一個媒體流的ICE重新啟動的話，agent會在answer中執(zhí)行兩種修改處理：

　　Agent必須修改answer中的a=ice-ufrag和a=ice-pwd。

　　Agent可能在answer消息中修改其部署層級。

　　針對媒體流，agent會修改SDP中其他屬性設(shè)置，屬性設(shè)置和和初始answer中的處理流程相同。針對此媒體流，在接下來的處理流程中，候選地址組會根據(jù)實際情況，可能會包括部分參數(shù)，無參數(shù)，或者包括前面的候選地址參數(shù)，并且可能包括全新采集的候選地址組。

　　如果agent收到一個offer，offer中包含了一個新的媒體流，針對此媒體流，就像agent在初始o(jì)ffer包含的媒體流一樣，agent必須在answer中設(shè)置相關(guān)的域值。在answer設(shè)置以后就會導(dǎo)致ICE重新啟動。

　　如果agent收到一個offer，offer中包含了一個媒體流，其端口設(shè)置為0的話，agent一定不能為此媒體流在answer中包含任何候選地址屬性，并且不應(yīng)該包含任何和ICE定義的相關(guān)屬性，例如foundation和component-id等。

　　這個章節(jié)將對在全場景部署環(huán)境中，在不同ICE運行狀態(tài)下對現(xiàn)存媒體流進(jìn)行的處理做詳細(xì)說明。這里要注意這三個參數(shù)環(huán)境，用戶名稱（ice- ufrag），密碼（ ice-pwd）和部署級別。除了agent已經(jīng)從offer消息中檢測到ICE重新啟動之外，用戶名稱（ice- ufrag），密碼（ ice-pwd）和部署級別必須維持不變。如果agent想修改其中一個屬性值的話，agent通過生成一個新的offer來重新啟動ICE。agent不能在answer消息重新啟動ICE處理流程。其他的流程取決于此媒體流的ICE運行狀態(tài)。筆者將結(jié)合不同remote-candidates屬性出現(xiàn)的以下三種狀態(tài)進(jìn)行討論。

　　如果針對一個媒體流的ICE的狀態(tài)處于運行狀態(tài)，并且此媒體流的offer已鎖定了remote-candidates屬性，構(gòu)建answer消息的規(guī)則和筆者上一篇關(guān)于offer生成的流程相同。

　　如果針對一個媒體流的ICE狀態(tài)處于完成狀態(tài)，并且此媒體流的offer已鎖定了remote-candidates屬性，構(gòu)建answer消息的規(guī)則和筆者上一篇關(guān)于offer生成的流程相同，另外，應(yīng)答方answerer一定不能在answer消息中包括a=remote-candidates屬性。

　　以上兩種狀態(tài)都是鎖定了remote-candidates屬性的。如果remote-candidates是一種可變狀態(tài)，出現(xiàn)了競爭條件的話，現(xiàn)存媒體流的處理就需要做另外處理。當(dāng)agent對端peer對一個媒體流已包含了ICE處理流程的話，主控方agent將會收到一個帶a=remote-candidates屬性的offer消息。出現(xiàn)在offer中的這個屬性用來處理介于offer接收和響應(yīng)接收之間的競爭條件，通知answerer接收方ICE將會選擇一個候選地址。關(guān)于競爭狀態(tài)的流程，讀者可以查閱RFC5246-appendix-B.6。接下來關(guān)于針對offer攜帶a=remote-candidates的處理流程完全取決于競爭條件中協(xié)商勝方的處理流程。

　　Agent為媒體流的每個構(gòu)件生成一個候選配對，它需要遠(yuǎn)端候選地址和本地候選地址，具體處理流程為：

　　設(shè)置遠(yuǎn)端候選地址等于offerer提供方中的默認(rèn)目的地地址。例如，針對RTP的m行和c行內(nèi)容，和RTCP的a=rtcp。

　　設(shè)置本地候選地址等于傳輸?shù)刂�，此傳輸�(shù)刂肥侵С衷趏ffer中a=remote-candidates同一構(gòu)件。

　　生成候選配對完成以后，agent看到候選配對會出現(xiàn)在有效列表中。如果有一個配對沒有出現(xiàn)在有效列表中的話，說明檢查流程失去了競爭條件。這樣的配對稱之為 "losing pair"（丟失的配對）。接下來，agent會在檢查列表中通過遠(yuǎn)端候選地址查找，查找所有遠(yuǎn)端候選地址等于丟失配對中的遠(yuǎn)端候選地址的配對，執(zhí)行以下流程：

　　如果這些配對中無配對在In-Progress處理狀態(tài)，并且至少一個配對是失敗狀態(tài)，這可能是因為網(wǎng)絡(luò)問題導(dǎo)致，例如可能發(fā)生了網(wǎng)絡(luò)隔離問題，嚴(yán)重的網(wǎng)絡(luò)丟包。這樣可能就沒有出現(xiàn)remote-candidates，agent應(yīng)該為此媒體流生成一個answer，然后為此媒體流重新啟動ICE流程。

　　如果這些配對中至少有一對配對在In-Progress處理狀態(tài)，agent應(yīng)該等待它們的檢查流程完成，并且當(dāng)每個檢查完成后，重新執(zhí)行這部分流程，直到再沒有丟失配對需要處理。

　　一旦完成了沒有再需要處理的丟失的配對以后，agent就可以生成一個answer消息。它必須為此媒體設(shè)置默認(rèn)目的地地址，默認(rèn)目的地地址為remote-candidates（來自于offer）中的候選地址。它必須為此每個候選地址在answer中包括一個候選地址屬性，這里的每個候選地址是在offer中remote-candidates屬性中。

　　如果在收到的offer中包含remote-candidates屬性，agent為媒體流的每個構(gòu)件生成一個候選配對，它需要遠(yuǎn)端候選地址和本地候選地址，具體處理流程為：

　　設(shè)置遠(yuǎn)端候選地址等于offerer提供方中的默認(rèn)目的地地址。例如，針對RTP的m行和c行內(nèi)容，和RTCP的a=rtcp。

　　設(shè)置本地候選地址等于傳輸?shù)刂�，此傳輸�(shù)刂肥侵С衷趏ffer中a=remote-candidates同一構(gòu)件。

　　針對此媒體流，agent然后把這些候選地址遷移到有效列表中。ICE處理流程狀態(tài)設(shè)置為完成狀態(tài)。

　　除了以上設(shè)置以外，agent控制角色也是一個問題需要討論。如果agent認(rèn)為它自己是主控方agent，而且在offer消息中包含了remote-candidates屬性，雙方agent都認(rèn)為自己是主控方agent。這種情況下，雙方agent將可能都已經(jīng)同時對對方發(fā)送了更新offer消息。這種極端情況需要負(fù)責(zé)傳輸offer/answer交互的信令協(xié)議來解決。最后，其中一方agent總是以競爭環(huán)境中的勝方出現(xiàn)。在信令協(xié)議傳輸offer/answer交互的流程中，對端peer發(fā)送offer之前，勝方agent會首先收到一個offer消息。勝方agent會充當(dāng)主控方agent的角色，因此，這里所討論的應(yīng)答方answerer必須修改其角色為主控方角色。接下來，如果agent基于一個流程（根據(jù)RFC5245-8.2.2）發(fā)送更新offer的話，這個agent就是一個主控方agent。

　　除了以上控制角色修改以外，構(gòu)建answer的執(zhí)行流程中關(guān)于有效列表中的修改和ICE狀態(tài)修改和構(gòu)建offer流程的相同。讀者可以查閱上一篇文章做進(jìn)一步了解。

　　本章節(jié)介紹了在更新的offer中關(guān)于接收offer消息和生成answer消息的處理過程。接下來的章節(jié)筆者將介紹在后續(xù)offer/answer交互中check更新和有效列表更新的細(xì)節(jié)。