I'm seeing the following errors in my MPC app in iOS 10 and I'm looking for some help explaining them. After the peers are connected, several of the errors below pop up. The peers end up connecting, but it is slower than in iOS 9 (appears that the event causing the error messages are occurring on the main thread). These errors do not appear in the app when running on an iOS < 10.
[ViceroyTrace] [ICE][ERROR] Send BINDING_REQUEST failed(C01A0041).
Not in connected state, so giving up for participant [47CD8292] on channel [0].
Any input would be greatly appreciated!
NAT
In order to explain the reason and meaning of error, we have to start with NAT (you can skip this part if you are familiar with it).
NAT is a way to mapping same 'global' IP address for multiple devices in the same local network, i.e. multiple devices share same address (may be in different time, may be using different port -- NAPT), in which way we can save a lot of 'global' address and ease the depletion of ipv4 address. And also because of this, devices's local address can only be used in LAN, not outside. The datagram want to send outside will go through NAT device (always a router) which will modify the address in header to global address. One more point is devices in the different LAN may use same IP address.
ICE
Now, we want to make to peer communicate directly, so we have to know peer's address. But as we know, the use of NAT make the address of devices just a local address which can't be used outside the Internet and fail to communicate using it. The purpose of ICE is to discover which address the peer should use to communicate directly with other peer.
Gather Candidates Addresses
The first phase it to gather candidates addresses:
In order to get the public side address, device will send a 'Binding request' to a public server (called STUN server, outside LAN) and server send back address called 'Binding response'.
Connectivity Checks
When devices has the addresses they have, they will send to other peer over the signaling channel. When peer (we call it 'R') receive list of addresses from our device (we call it 'L'), R will collect its own addresses and respond its own list. At the end of this process, it result in CANDIDATE PAIRS. To see which pairs work, each agent schedules a series of CHECKS with 'Binding request' & 'Binding response'.
Conclusion
So in conclusion, possible reasons before more details:
Suggestions:
Ref: