- 整體部署場(chǎng)景討論（檢測ICE重新啟動(dòng)，移除媒體流，增加媒體流）
- 全場(chǎng)景部署討論：無(wú)remote-candidates屬性狀態(tài)下，ICE運行時(shí)現存媒體流處理和ICE完成后現存媒體流處理，帶remote-candidates現存媒體流處理。
- 輕量級場(chǎng)景部署討論：ICE運行時(shí)現存媒體流處理和ICE完成后現存媒體流處理。
讀者注意，在這里討論的offer/answer已經(jīng)涉及到了后續offer的內容，也就是更新的offer，所以有時(shí)會(huì )和初始offer時(shí)的一些屬性進(jìn)行對比處理，讀者一定不要迷惑。
1、整體部署場(chǎng)景討論
當agent在現存會(huì )話(huà)中收到后續offer時(shí)，無(wú)論前面的offer/answer交互驗證是否成功，agent必須重新檢查一次驗證ICE支持能力（前面的文章中介紹過(guò)接收初始offer關(guān)于ICE能力支持驗證流程）。雖然，前面offer/answer交互可能導致ICE不能使用，不過(guò)，這種處理結果可以作為后續offer/answer交互的結果使用。和上一篇文章中所討論的應用，agent接收offer時(shí)，對于整體部署場(chǎng)景來(lái)說(shuō)，仍然需要執行常規的三個(gè)步驟的處理：檢測ICE重新啟動(dòng)，添加媒體流處理，移除媒體流處理。現在，我們分別加以介紹。
用戶(hù)屬性發(fā)生了修改，agent需要重新檢測并且重新啟動(dòng)ICE。具體來(lái)說(shuō)，agent和前面收到的SDP中屬性對比，如果agent在收到的更新offer消息中包含了一個(gè)已修改的屬性（可能是a=ice-ufrag 或者a=ice-pwd），針對此媒體流，agent需要重新啟動(dòng)ICE。如果所有的媒體流需要重新啟動(dòng)的話(huà)，所有ICE也需要重新啟動(dòng)。如果一個(gè)媒體流的ICE重新啟動(dòng)的話(huà)，agent會(huì )在answer中執行兩種修改處理：
- Agent必須修改answer中的a=ice-ufrag和a=ice-pwd。
- Agent可能在answer消息中修改其部署層級。
針對媒體流，agent會(huì )修改SDP中其他屬性設置，屬性設置和和初始answer中的處理流程相同。針對此媒體流，在接下來(lái)的處理流程中，候選地址組會(huì )根據實(shí)際情況，可能會(huì )包括部分參數，無(wú)參數，或者包括前面的候選地址參數，并且可能包括全新采集的候選地址組。
如果agent收到一個(gè)offer，offer中包含了一個(gè)新的媒體流，針對此媒體流，就像agent在初始offer包含的媒體流一樣，agent必須在answer中設置相關(guān)的域值。在answer設置以后就會(huì )導致ICE重新啟動(dòng)。
如果agent收到一個(gè)offer，offer中包含了一個(gè)媒體流，其端口設置為0的話(huà)，agent一定不能為此媒體流在answer中包含任何候選地址屬性，并且不應該包含任何和ICE定義的相關(guān)屬性，例如foundation和component-id等。
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）和部署級別。除了agent已經(jīng)從offer消息中檢測到ICE重新啟動(dòng)之外，用戶(hù)名稱(chēng)（ice- ufrag），密碼（ ice-pwd）和部署級別必須維持不變。如果agent想修改其中一個(gè)屬性值的話(huà)，agent通過(guò)生成一個(gè)新的offer來(lái)重新啟動(dòng)ICE。agent不能在answer消息重新啟動(dòng)ICE處理流程。其他的流程取決于此媒體流的ICE運行狀態(tài)。筆者將結合不同remote-candidates屬性出現的以下三種狀態(tài)進(jìn)行討論。
如果針對一個(gè)媒體流的ICE的狀態(tài)處于運行狀態(tài)，并且此媒體流的offer已鎖定了remote-candidates屬性，構建answer消息的規則和筆者上一篇關(guān)于offer生成的流程相同。
如果針對一個(gè)媒體流的ICE狀態(tài)處于完成狀態(tài)，并且此媒體流的offer已鎖定了remote-candidates屬性，構建answer消息的規則和筆者上一篇關(guān)于offer生成的流程相同，另外，應答方answerer一定不能在answer消息中包括a=remote-candidates屬性。
以上兩種狀態(tài)都是鎖定了remote-candidates屬性的。如果remote-candidates是一種可變狀態(tài)，出現了競爭條件的話(huà)，現存媒體流的處理就需要做另外處理。當agent對端peer對一個(gè)媒體流已包含了ICE處理流程的話(huà)，主控方agent將會(huì )收到一個(gè)帶a=remote-candidates屬性的offer消息。出現在offer中的這個(gè)屬性用來(lái)處理介于offer接收和響應接收之間的競爭條件，通知answerer接收方ICE將會(huì )選擇一個(gè)候選地址。關(guān)于競爭狀態(tài)的流程，讀者可以查閱RFC5246-appendix-B.6。接下來(lái)關(guān)于針對offer攜帶a=remote-candidates的處理流程完全取決于競爭條件中協(xié)商勝方的處理流程。
Agent為媒體流的每個(gè)構件生成一個(gè)候選配對，它需要遠端候選地址和本地候選地址，具體處理流程為：
- 設置遠端候選地址等于offerer提供方中的默認目的地地址。例如，針對RTP的m行和c行內容，和RTCP的a=rtcp。
- 設置本地候選地址等于傳輸地址，此傳輸地址是支持在offer中a=remote-candidates同一構件。
生成候選配對完成以后，agent看到候選配對會(huì )出現在有效列表中。如果有一個(gè)配對沒(méi)有出現在有效列表中的話(huà)，說(shuō)明檢查流程失去了競爭條件。這樣的配對稱(chēng)之為 "losing pair"（丟失的配對）。接下來(lái)，agent會(huì )在檢查列表中通過(guò)遠端候選地址查找，查找所有遠端候選地址等于丟失配對中的遠端候選地址的配對，執行以下流程：
- 如果這些配對中無(wú)配對在In-Progress處理狀態(tài)，并且至少一個(gè)配對是失敗狀態(tài)，這可能是因為網(wǎng)絡(luò )問(wèn)題導致，例如可能發(fā)生了網(wǎng)絡(luò )隔離問(wèn)題，嚴重的網(wǎng)絡(luò )丟包。這樣可能就沒(méi)有出現remote-candidates，agent應該為此媒體流生成一個(gè)answer，然后為此媒體流重新啟動(dòng)ICE流程。
- 如果這些配對中至少有一對配對在In-Progress處理狀態(tài)，agent應該等待它們的檢查流程完成，并且當每個(gè)檢查完成后，重新執行這部分流程，直到再沒(méi)有丟失配對需要處理。
- 一旦完成了沒(méi)有再需要處理的丟失的配對以后，agent就可以生成一個(gè)answer消息。它必須為此媒體設置默認目的地地址，默認目的地地址為remote-candidates（來(lái)自于offer）中的候選地址。它必須為此每個(gè)候選地址在answer中包括一個(gè)候選地址屬性，這里的每個(gè)候選地址是在offer中remote-candidates屬性中。
3、輕量級部署環(huán)境處理流程
如果在收到的offer中包含remote-candidates屬性，agent為媒體流的每個(gè)構件生成一個(gè)候選配對，它需要遠端候選地址和本地候選地址，具體處理流程為：
- 設置遠端候選地址等于offerer提供方中的默認目的地地址。例如，針對RTP的m行和c行內容，和RTCP的a=rtcp。
- 設置本地候選地址等于傳輸地址，此傳輸地址是支持在offer中a=remote-candidates同一構件。
針對此媒體流，agent然后把這些候選地址遷移到有效列表中。ICE處理流程狀態(tài)設置為完成狀態(tài)。
除了以上設置以外，agent控制角色也是一個(gè)問(wèn)題需要討論。如果agent認為它自己是主控方agent，而且在offer消息中包含了remote-candidates屬性，雙方agent都認為自己是主控方agent。這種情況下，雙方agent將可能都已經(jīng)同時(shí)對對方發(fā)送了更新offer消息。這種極端情況需要負責傳輸offer/answer交互的信令協(xié)議來(lái)解決。最后，其中一方agent總是以競爭環(huán)境中的勝方出現。在信令協(xié)議傳輸offer/answer交互的流程中，對端peer發(fā)送offer之前，勝方agent會(huì )首先收到一個(gè)offer消息。勝方agent會(huì )充當主控方agent的角色，因此，這里所討論的應答方answerer必須修改其角色為主控方角色。接下來(lái)，如果agent基于一個(gè)流程（根據RFC5245-8.2.2）發(fā)送更新offer的話(huà)，這個(gè)agent就是一個(gè)主控方agent。
除了以上控制角色修改以外，構建answer的執行流程中關(guān)于有效列表中的修改和ICE狀態(tài)修改和構建offer流程的相同。讀者可以查閱上一篇文章做進(jìn)一步了解。
本章節介紹了在更新的offer中關(guān)于接收offer消息和生成answer消息的處理過(guò)程。接下來(lái)的章節筆者將介紹在后續offer/answer交互中check更新和有效列表更新的細節。
