STUN server address is incompatible | Error code=701:

Question

I have installed the TURN server everything in the server code is working fine. no error in the log file. only a warning stating

 0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided

but the TURN server running on the server.

here is what shows when I check lsof -i :3478

turnserve 999 root   15u  IPv4 446811411      0t0  TCP domain.com:stun (LISTEN)
turnserve 999 root   23u  IPv4 446811417      0t0  TCP domain:stun (LISTEN)
turnserve 999 root   24u  IPv4 446810998      0t0  UDP domain.com:stun
turnserve 999 root   25u  IPv4 446810999      0t0  UDP domain.com:stun

when I check STUN in Trickle ICE it throws an errors

The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN server address is incompatible.
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN allocate request timed out.

what's going wrong in this.

Thank you

Answer 1

I think that 701 error is a more generic connectivity error that Trickle ICE uses to indicate it didn't get a binding response back. Run stunclient your.stun.ip.address with the command line tools at www.stunprotocol.org to see if your STUN service is accessible from the outside world.

STUN technically requires being hosted on a device with two IP addresses and two ports. It's typically a command line parameter to specify which IP addresses the server should listen on. But most server implementations can operate on a host with a single IP address.

The second IP address and port on the server is used for STUN client filtering tests to detect what type of NAT is in effect. The client sends a binding request on the server's primary ip and port, but with a change request attribute to have the server respond from the alternate IP address or port. More often than not, this binding request with a change-request attribute fails since NATs will not forward traffic from the other IP/port.

The filtering test is useful for logging what type of NAT the client is on. So that failed connections can be debugged and that success/failure metrics can be correlated to NAT type.

Since most ICE implementations will exchange all available address candidates (local, mapped, and relay), the filtering test isn't very or useful to connectivity establishment.

I'm surprised Trickle ICE is giving you an error. I didn't think WebRTC ever used the changer-request attribute. I just did a Wireshark trace of a Trickle ICE session to stun.stunprotocol.org. I don't see the webrtc client setting the change-request attribute in either of the two binding requests it makes.

More details in RFC 5780 Section 3.2

Answer 2

In macOS, I just do so:

> brew install stuntman

when it done

> stunclient stun.stunprotocol.org
Binding test: success
Local address: 198.18.0.1:54898
Mapped address: 210.0.158.130:56750

To specify port, just like this:

> stunclient stun.stunprotocol.org 3478
Binding test: success
Local address: 198.18.0.1:63061
Mapped address: 210.0.158.130:37126

Have fun!