#545 Re-registers (only) result in STUN failures

[Anonymous]

Originally created by: dc3de...@gmail.com
Originally owned by: r3gis...@gmail.com

What steps will reproduce the problem?
1. Configure the application for STUN resolution
2. Kill it completely with task killer to assure service it killed
3. Cold-start the application, see it immediately register with SIP switch
4. Go into menu/settings/filters, select an account
5. Exit all the way back to main screen

What is the expected output? What do you see instead?

Expected: Re-register (SIP account briefly disappears then re-appears)
Saw: SIP account disappears, followed by a series of toasts about STUN failures. Occasionally it will successfully re-register after one or two STUN faillures, but usually it simply fails to re-register, leaving only the Mobile icon.

Please use labels and text to provide additional information.

This only happens some of the time, maybe 30%. When it DOES happen, in order to get the phone to work I must kill it completely and fresh start it. This never happens on a fresh start; the STUN immediately resolves and the SIP account registers. Thus, my STUN server/port is correct and the STUN server is really working.

The fact that it only happens some of the time, and never on a cold start, makes this defect report suspicious. Anyway I thought I would report it.

[Anonymous]

Originally posted by: dc3de...@gmail.com

Oh, the STUN errors are, first a few of these:

Fail to add media transport Received no response from STUN server (PJLIB_UTIL_ESTUNNOTRESPOND)

then eventually this:

Fail to create transport Received no response from STUN server (PJLIB_UTIL_ESTUNNOTRESPOND) (320010)

[Anonymous]

Originally posted by: dc3de...@gmail.com

Just found that multiple STUN servers are supported, so made changes to prefs strings in [r525]. With two STUN servers configured (stun.3cx.com,stun.counterpath.com) I cannot reproduce the problem.

Status: Started

[Anonymous]

Originally posted by: dc3de...@gmail.com

Further testing has clarified when the problem occurs. It doesn't matter where in Settings you are, it is how long you stay in Settings. If you stay in a settings screen "too long" then when you come back out, the STUN fails to resolve. I looked at the code and the high-level STUN usage is quite simple, just configuring a non-zero number of stun servers, and filling in the host/IP for each.

This looks like a pjsip problem, and I am not knowledgeable in that area. I'm guessing that something must need to be done during pjsua.csipsimple_destroy() for the stack, or there is a bug in the stack when it is re-initialized or ???

I'm going to switch this back to New and assign it to regis. Sorry!

Owner: r3gis.3R
Status: New

[Anonymous]

Originally posted by: r3gis...@gmail.com

Extremely interesting :)

I'll have a look to that point. It's probably not managed properly on my side you're right.

[Anonymous]

Originally posted by: christop...@gmail.com

I'm having this issue and as STUN is the only way I can get inbound audio to function, this is critical.

It does not seem to be an issue with the settings menu at all, occasionally I'll run into a WiFi connection disruption and when CSipSimple tries to re-register I'll get the STUN not responding message. It recovers randomly, sometimes I can exit and go back in and it'll register right away. However right now I just hit it and it's been over five minutes and I still get the message, even after trying Disconnect from the menu a few times.

[Anonymous]

Originally posted by: r3gis...@gmail.com

For info after a lot of tests I found a more solid repro scenario.
When DNS SRV is activated and STUN also activated pjsip frequently fail in this kind of problem.

I'll try to debug this issue a little bit more. But if you have DNS SRV activated and that's actually not really required (anyway should never be absolutely required if you use expert account), you could maybe improve things by disabling DNS SRV.

[Anonymous]

Originally posted by: ferna...@bugabundo.net

I can confirm this only happens (or is much more frequent) with Incoming enabled

[Anonymous]

Originally posted by: simon.bl...@gmail.com

Same problem here. Happens when I enter the settings. Can only be fixed by restarting the phone.

[Anonymous]

Originally posted by: r3gis...@gmail.com

I'm trying to debug it.

After investigation :
* I fixed one thing that produced this error each time there is an incoming call. It should be included in latest build. (I made a mistake when including zrtp lib and it broke restart).

* Now I observe some other problem. It happens when STUN (without ICE) is used. In this case, after 2 restart of the stack (for example if you go in setting and press back), it break the stun resolution which block registration. I have no idea why yet. The only thing I can say is that activating ICE (which result in using another stun implementation of pjsip) solve the problem. I think there is something wrong in the old STUN method of pjsip. (and this old method is the one used when not activating ICE).
So, if you have the problem, you can simply activate ICE and use latest dev version so that you'll not experiment stun errors anymore.
But I'd like to understand why the old pjsip stun implementation fails when restarting the stack. There is maybe something they forgot to stop cleanly.

Status: Started

[Anonymous]

Originally posted by: ferna...@bugabundo.net

I have todays trunk in two Desire HD with nightly CM7 and this still happens (without ICE)

[Anonymous]

Originally posted by: r3gis...@gmail.com

Yes with STUN without ICE, I reproduce too. After the second restart only. That's really weird. I'm trying to dive into pjsip code to understand what's happening.

As workaround I think that activating ICE will help (at least on my side when I activate it problems disappear). As ICE covers all features of STUN + better features that's not a so bad workaround ;).

[Anonymous]

Originally posted by: r3gis...@gmail.com

This issue was closed by revision [r753].

Status: Fixed