signalserver去掉後，端A和端B通過交換sdp、icecandiate信息建立p2p連接，比如端A爲連接發起方，生成本地的sdp、icecandiate信息，端B拿到端A的這些信息後，設置爲自己的遠端sdp和遠端icecandiate，端B也會獲取自己的sdp、icecandidate信息，將這些信息讓端A知道，A在AddIcecandidate端B的每條icecandidate信息時，端A將都會建立一個connection並將其存在一個std::vector<Connection *> connections_容器中，然後逐個嘗試去ping icecandidate中的連接地址，如果能夠收到回覆，會觸發Connection::ReceivedPingResponse，這樣就算建立了一條成功的p2p connection,這樣處理了多條icecandidate後，最後還是得從connections_中依據比較規則選出最優的connection，這就是大概的一個過程。
現在說說遇到的一個問題和對應的處理辦法，一端處理sdp、icecandidate信息建立一個個connection後會有一個Ping的過程，這是是要花些時間的，經過測試往往在這個過程會出現整個icesession的狀態會從kIceConnectionChecking變成kIceConnectionFailed的情況，這個時候就算雙方成功建立了p2p連接通道，某一方還是會出現斷言錯誤，導致無法調試，斷言處是WebRtcSession::SetIceConnectionState函數中 switch (ice_connection_state_)的case kIceConnectionFailed下，之前以爲真的是雙方無法建立connection,後來調試發現就算是這種情況下，雙方的ReceivedPingResponse卻是響應的，於是嘗試將case kIceConnectionFailed下的斷言去掉，端A嘗試給端B發送message,端B居然能夠收到，這個時候我有了個構想，也許是我在交換端A和端B的sdp、icecandiate信息的時候花費了太多的時間，導致一端正在ping，另一端其實都未來得及建立自己本地的peerconnection，當然Ping的那端過一段時間肯定會報10051錯誤，會將IceConnectionState置爲kIceConnectionFailed，也就是“向一個無法連接的網絡嘗試了一個套接字操作。”，好在Ping這個過程並不是遇到Ping不通就停止Ping,而是隻要連接發起就不斷地Ping下去，當接受p2p連接的那端建立了本地的peerconnection開始Ping的時候，雙方就都能Ping通對方了！這時之前Ping失敗的那方想使用SetIceConnectionState設置本段爲kIceConnectionConnected的時候，問題就出來了，查閱代碼，SetIceConnectionState下的規定，如果要設置IceConnectionState爲kIceConnectionConnected，那麼IceConnectionState當前的就不能是kIceConnectionFailed，若是就觸發了ASSERT(state == PeerConnectionInterface::kIceConnectionNew)斷言，這也不是webrtc的疏忽，按照存在signalserver的情況來說，雙方交換自己的sdp、icecandidate信息都是通過signalserver中轉的，比我們手動交換信息的速度快多了，很少機率會有我們上面說的那個問題，誰讓你自己把signalserver切掉，自己手動通過qq傳文件的方式來交換端A和端B的sdp、icecandiate信息呢，所以說如果要測試手動交換雙方的信息這種方式，那麼還是將ASSERT(state == PeerConnectionInterface::kIceConnectionNew)這條斷言註釋掉吧，不過在使用signalserver作爲中轉的時候要加上！
