Multipeer "Error sending BINDING_REQUEST failed" connection error in iOS10

I see the following errors in my MPC application in iOS 10, and I'm looking for some help explaining them. After connecting peers, a few errors appear below. Peer-to-peer connections end with a connection, but it is slower than in iOS 9 (it appears that the event causing the error messages occurs in the main thread). These errors do not appear in the application when launched on iOS <10.

[ViceroyTrace] [ICE][ERROR] Send BINDING_REQUEST failed(C01A0041). Not in connected state, so giving up for participant [47CD8292] on channel [0]. 

Any entry is welcome!

+5
source share
1 answer

cause and meaning of error

NAT

To explain the cause and meaning of the error, we should start with NAT (you can skip this part if you are familiar with it).

NAT is a way of matching the same "global" IP address for multiple devices on the same local network, i.e. several devices use the same address (maybe at different times, another port can be used - NAPT), how we can save a lot of "global" address and facilitate the depletion of ipv4 address. And also because of this, the local address of the device can only be used on the local network, and not outside. The datagram wants to send external information through a NAT device (always a router), which will change the address in the header to the global address. Another point is that devices on different LANs can use the same IP address.

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

ICE

Now we want peer-to-peer communication to be direct, so we need to know the address of the peer-to-peer network. But, as we know, using NAT makes the device address only a local address that cannot be used outside the Internet and cannot communicate with it. The purpose of the ICE is to determine which address the peer should use for direct communication with another partner.

Collect candidate addresses

At the first stage, he collects the addresses of the candidates:

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

To get the address of the public side, the device will send a “binding request” to a public server (called a STUN server, outside the local network) and a server sending address called “binding response”.

Connection check

When devices have their own addresses, they will send to other partners via the signaling channel. When a peer (we call it "R") receives a list of addresses from our device (we call it "L"), R will collect its own addresses and respond to its own list. At the end of this process, this will result in CANDIDATE PAIRS . To see which pairs work, each agent plans a series of CHECKS with a “Binding Request” and “Binding Response”.

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

Conclusion

So, in conclusion, possible reasons for more details:

  • unable to connect to the STUN server;
  • normal failure when checking a pair of addresses;

Suggestions:

  • check the ICE phase information to see the differences in ICE implementation between ios10 and others.
  • This thread is some discussion about the mpc error that might inspire you.

Ref:

+6
source

Source: https://habr.com/ru/post/1261835/


All Articles