News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

STUN support problem

Started by OZOi, September 01, 2011, 01:55:12 PM

Previous topic - Next topic

OZOi

Here is yet another problem with OBi100, 1.2.1 (Build: 2384). This time it is with STUN implementation.

I need OBi to send SIP requests with SDP containing WAN (not LAN) address. In order to do so I have to configure it in "Service Providers | ITSP Profile X | General" page and set followed options:
STUNEnable - enable
STUNServer - host name of STUN server

I tried to use public STUN servers:
stun.ideasip.com
stun.counterpath.com
Both servers are reliable and work very well with other SIP clients.

Now, when I set OBi100 to send WAN IP, more often then not when I dial OBi will pause for 40 sec and then it sends requests with SDP, containing LAN (not WAN) IP. Which makes call impossible, of course - there is no audio... Sometimes it gets WAN IP and uses it immediately to make a call with proper WAN IP. Similar scenario happens when I receive calls...

The current STUN support implementation is completely unreliable. Please fix it ASAP.

Thank you.

BTW, how often do you think OBi changes its WAN address? Thus, why OBi has problem with WAN IP resolution 3 times form may be every 4-5 attempts?

RonR

Quote from: OZOi on September 01, 2011, 01:55:12 PM
Now, when I set OBi100 to send WAN IP, more often then not when I dial OBi will pause for 40 sec
.
.
.
The current STUN support implementation is completely unreliable. Please fix it ASAP.

Don't get your hopes up.

An unreachable STUN server results in a timeout of 40 seconds in the OBi before it continues on without it.  I reported this problem via email to Obihai support back on 3/22/2011 but never got a reply.  It's also been mentioned several times here on the forum with no comment and no resolution.

OZOi

But I need this functionality very badly. It could soon become a choice - either to continue to use OBi100 or just drop it and move on... :(

I hope they better read and pay attention to these problems...

OZOi

Running the latest v.1.3.0.2532 and it looks like the problem with STUN server is fixed here.

Thanks a lot guys!

RonR

Quote from: OZOi on September 16, 2011, 08:20:18 PM
Running the latest v.1.3.0.2532 and it looks like the problem with STUN server is fixed here.

You might want to check again.

An unreachable STUN server still produces a 40 second delay in 1.3.0 (Build: 2532).

Set your STUN server to stun01.sipphone.com and make a call on SP1 or SP2 (whichever uses SIP).  In approximately 40 seconds, the call will actually start.

OZOi

RonR, I think you're right. I've tried stun01.sipphone.com and it produced the same results as you've reported (40 sec delay and LAN IP after that). At this time I guess we have a problem with that particular STUN server.

I've checked my OBi again with followed two servers and both are working well now:
stun.ideasip.com
stun.counterpath.com
They have exhibited 40 sec problems with v.1.2.1 though...

Try one of the servers mentioned above and let us know your experience.

RonR

#6
This particular problem is with a STUN server that's not responding.  The OBi has a timeout of 40 seconds, which is utterly ridiculous.  A PAP2, for example, times out in approximately 1 second if the STUN server doesn't respond.

stun01.sipphone.com was the Gizmo5 STUN server and worked fine until it was taken down when Gizmo5 shut down.  When I finally figured out the huge delays I was experiencing was due to stun01.sipphone.com being down, I switched to stun.ideasip.com and have been using it since.

OZOi

I agree. The right solution in a situation, when STUN server is not responding, is not to delay receiving/making call for 40 sec, but rather to send error to SIP server as soon as the problem is recognized. Trying to continue call with sending LAN IP after 40 sec delay is plain futile. There will be no audio anyway.