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作为中转的时候要加上！
