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