Cannot get STUN to work... works on other devices

[AndyJ]

I can't get STUN to work on the OBi110. When I enable STUN, I get the 40 second timeout before the call is connected. If I run a STUN client from other devices on the same LAN, using the same STUN server, it works fine:

stunc stun.xten.com:3478 -b
assign_socket: local socket is bound to 0.0.0.0:44395
stunc_bind_cb: stun_discovery_done
stunc_bind_cb: local address NATed as xxx.xxx.xxx.xxx:44395

I've tried various STUN servers, and the result is the same - they all fail on the OBi110, but work fine on other devices. The NAT is a Port Restricted Cone NAT:

stunc stun.xten.com:3478 -n
assign_socket: local socket is bound to 0.0.0.0:58819
stunc_nattype_cb: stun_discovery_done
stunc_nattype_cb: NAT type determined to be 'Port Restricted Cone NAT (endpoint independent mapping)' (6).

[RonR]

There is a known problem in the OBi that's never been fixed where the timeout on a non-existent STUN server is 40 seconds.

I'm not having any problems using stun.ideasip.com

I avoid xten's STUN server as it's frequently problematic.

[AndyJ]

This works fine for other devices on the same LAN, so I don't know why it's not working on the OBi110, regardless of the server used. Every server that I've tried works on other clients, but fails on the OBi110. Perhaps it has something to do with the type of NAT.

[RonR]

If you've got a couple you'd like me to test here, I'd be happy to do so.

[AndyJ]

I tried the stun.ideasip.com server that you suggested - same issue... works on my PC (almost instant response), but fails on the OBi110. I also just tried stun.ekiga.net, with similar results. It looks like the OBi110 is having trouble dealing with my NAT.

[obi-support2]

Just tried stun.ideasip and stun.ekiga.net on my OBi110 and they both worked fine.
(My DNS on the other hand cannot resolve stunc.stun.xten.com).

If it takes 30+ s for the call to start, either
a) the OBI device STUN packets are not getting through to the STUN server, or
b) the OBI device is not getting any response from the STUN server(s)

[AndyJ]

It's just stun.xten.com... stunc is a command-line stun client that I was using to test from other devices :-) (i.e. stunc ... is the command line I was typing, with the response shown below).

So, it looks like the OBi has trouble dealing with some NATs, since the stunc client, run from systems on the same LAN, is able to get the NATed address just fine. There is nothing special set in the router for those other systems. Softphones also are able to work fine, but the OBi fails at STUN. I'd blame the router, since many of them have quirky NAT implementations, but the fact that other systems can use STUN fine through that same router leads me to believe the problem is elsewhere.

[AndyJ]

An update on this... I got a new router, and STUN still fails on the OBi110, while it succeeds on other devices. I wonder if my ISP is blocking a specific port being used by the OBi110.

Questions:
(1) Is there any way to get more detailed information on the STUN attempt? There doesn't seem to be much, even when debugging is enabled.
(2) What port does the OBi110 use as the source/local port? Does it pick a random port, or does it use a specific port every time?

[Answering the 2nd question myself after thinking about it... the local port should be in the RTP port range, since the OBi110 is attempting to determine what port the local port is mapped to by the NAT. The OBi110 can receive UDP packets in that port range, so I don't know why it's having a problem when attempting STUN.]

[OZOi]

What firmware version is installed on your OBi device?
I have positive results with v.1.3.0.2532. See this thread for some details.

[AndyJ]

I'm using 1.3.0 (2532). This has never worked for me, regardless of the version. Every STUN server always times out, even though they work fine with other applications. I've tried all sorts of things (port forwarding, etc), but can't figure out why STUN servers work fine for all the other devices on my network, but not the OBi110.

[OZOi]

I've just tried "stun.xten.com" and it works well with OBi100 v.1.3.0.2532 for me.
There is no delay for both outgoing and incoming calls and OBi used correct WAN IP.

[AndyJ]

That's one of the many STUN servers that I've tried. I'll try it on the OBi110, and experience the STUN failure, and then immediately try it on another device on the same LAN, and see success on that device. There's something peculiar to the OBi110 that is causing it to fail in my environment.

Maybe if I have a chance, I'll set up a STUN server on my LAN and point the OBi110 to it. Of course, it will not give correct results, but I could at least trace the traffic to see if there's anything odd in the OBi110's request.

[OZOi]

If you'll find a STUN server, which is very lite on resources and running on Windows platform (preferably as service, so it'll be restarted by OS itself) - let me know. I'll install and check it too. I need to see what's going on here too.

I presume the cause of the problem is in different implementations of the STUN protocol spec. Those servers, that do not work with OBi, may "talk slightly different dialect", which is not understood or rejected by OBI... Other devices, that work fine, are perhaps just less fastidious...

To get proper results, you have to run STUN server on a public IP, which is different from IP of SIP server and from OBI device.

[AndyJ]

ARGH! After all this time, I've found the problem.

If an outbound proxy is defined in an ITSP profile, then the STUN server DOES NOT WORK if "op=s" is specified in a voice gateway using that profile. I'm guessing that the STUN request is being sent to the outbound proxy instead of directly to the STUN server. The provider I'm using requires registration requests to be sent to the outbound proxy server, so I don't need the STUN server for that. However, I have voice gateways defined with the "op=s" (use STUN) option. If the outbound proxy is enabled, the STUN request times out. If I remove the outbound proxy, then STUN works! (But, in that case, I cannot register with the ITSP anymore, since they require use of the outbound proxy for registration).

I found this by setting up a STUN server on my LAN (stund under Linux). As I mentioned earlier, it obviously wouldn't give the correct results, but would at least help to see what the OBi110 is doing. When I had the OutboundProxy defined, and made a call with VG1 (with op=s), the local STUN server DID NOT receive any request, but I still saw the 40 second delay before the call started, typical of the STUN failure. So, it seems like the OBi110 made a STUN request, but not to the local STUN server. After I removed the OutboundProxy and made the same call with VG1, I saw the OBi110 make the request to the local STUN server and continue with the call.