Multipeer Connectivity Error "Send BINDING_REQUEST failed" in iOS10

Question

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!

Answer 1

the reason and meaning of the error

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.

                 |
                 | /------------  'Global'
          X1':x1'|/               Address
           +------------+         
           |    NAT     |
           +------------+
                 |
                 | /------------  Local
             X:x |/               Address
             +--------+
             |        |
             | Agent  |
             |        |
             +--------+

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:

• address of its interface
• translated addresses on the public side of a NAT (SERVER REFLEXIVE CANDIDATES)
• (optional): addresses on TURN servers (RELAYED CANDIDATES)

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'.

L                        R
-                        -
STUN request ->             \  L's
          <- STUN response  /  check

           <- STUN request  \  R's
STUN response ->            /  check

Conclusion

So in conclusion, possible reasons before more details:

• fail to connect to STUN server;
• the normal failure when testing address pair;

Suggestions:

• check the info about the phases of ICE to know the differences of ICE implementations between ios10 and others.
• This thread is some discussions about the bug of mpc, which may inspire you.

Ref:

• ICS RFC
• NAT