#1136 Registration reliability tracking issue

[Anonymous]

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

There are two groups of problems:
1. Time-to-time CSS looses registration, then it starts registering again by itself
2. CSS may fall into a state, where it doesn't send REGISTER requests anymore. Manual push is required

First group of cases - the reason perhaps is irregularity in sending REGISTER requests. If "expired" time set to, let say, 10 min, it may send next request in 12 min or more (sometimes the delay could be an hour or even more). During the time, when it's late, CSS is obviously unregistered from VoIP provider and can't get incoming calls. At the same time it could send REGISTER requests earlier, then configured. E.g. it may send next request in 1 or 2 min after the last one, making unnecessary registrations... See example posted in <a href="https://code.google.com/p/csipsimple/issues/detail?id=81#c86">Comment #86</a>.

Second group of cases - I've noticed that CSS may suddenly just stop sending REGISTER requests at all. At that time other accounts (I keep several accounts active at a time) continue to make registrations as usual...

The message, when it's stuck, could be:
Error while registering -
Unauthorized

If I catch that (for example, in a morning I may discover that it's stuck for the whole night) I may deactivate the account and then activate it again. It registers immediately (there is no "Unauthorized" problem, of cause). That's very dangerous scenario - I think it's registered with VoIP provider, while it's not and I can't get any calls, of cause :(

The worst scenario though is when CSS gets stuck showing, that it's registered, while it's not. See my <a href="https://code.google.com/p/csipsimple/issues/detail?id=1066#c5">comment #5</a>. Fortunately it happens in very rare occasions.

Note: in all cases cell phone is completely idle (no any user interaction with the phone). Watching registration status was done by checking VoIP provider's status page and SIP server log.

I'm sorry, but it's very frustrating to see how unreliable is SIP registration process in CSS :(

What steps will reproduce the problem?
1. Watch for registration status with VoIP provider
2. Push CSS to make registration, if it's stuck with "Unauthorized" error 
3. Check, if CSS is really registered, or it's only shows, that it is, while it's not (check VoIP provider's status to see that)

What is the expected output? What do you see instead?
CSS is registered with VoIP provider(s) all the time

What version of the product are you using? On what operating system?
Latest market build, 0.02-03 [r944]
Android 2.1

Please provide any additional information below.

[Anonymous]

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

OK, here is the latest experience. Look at today's log made by FreeSWITCH (I had two active accounts configured in CSS: one with FS and another one with VoIP provider). It contains timestamps of REGISTER requests, coming from CSS. Keep in mind that registration period is set to 10 min.
http://pastebin.com/MnG92fHC

As you can see, the night begun quite well. CSS registered every 10 min. But then, after 00:31:00, things started to get bizarre... There are multiple registrations at the same time, registrations in one minute period, late registrations and registration complete out of any array... Finally, it stopped working at all (the log provided was taken at 11:00, not at 09:14:33, the last event registered).

Now, when I checked CSS (accessing from status bar) - it indicated, that both accounts were active (providers indicated - they were not, of cause). I tired to make them inactive manually. Weird thing is, the green bar below wizard icon got black, while the account name still green with the note - "Registered". Toggling them multiple times did not help. Closing CSS via its menu "Disconnect" did not work... It still running. Only killing by Task Manager finally helped.

During the night I did not touch the phone. It was idle with screen off. CSS suddenly stopped working during that time (no any activity from my side initiated that).

Something is seriously wrong with registration scheduler.

[Anonymous]

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

Is it only me, who has been experiencing the issue?
If it's not, is there any chance that this problem will be fixed?
If it will - when? It's been almost two weeks, since this ticket was opened, and it seems like this very important issue is simply abandoned...

BTW, this night around 4:00AM, CSipSimple has suddenly stopped registering. When I discovered that, there was no CSipSimple icon on Status bar. But Android Task Manager displayed, that CSipSimple still running. Killing it with Task Manager eventually helped to restart its registering with SIP server...

[Anonymous]

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

Issue 1163 has been merged into this issue.

[Anonymous]

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

Issue 912 has been merged into this issue.

[Anonymous]

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

Issue 999 has been merged into this issue.

[Anonymous]

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

Issue 1072 has been merged into this issue.

[Anonymous]

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

Issue 859 has been merged into this issue.

[Anonymous]

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

@yok.. :
1st : the issue is not abandonned at all
2nd : I develop CSipSimple on my free time... this is absolutely not professional support, if you want apps with a pro support there is tones of paid sip apps on android market ;)
3rd : it take me time to get this fixed cause I do not reproduce that on sip providers I use (and besides I have no asterisk setup to debug this issue in details)

So => be indulgent AND feel fee to contribute the app !!!

To all : There were already opened issue abut that 859, 912, 999, 1072, 1163. I merged all in this one cause it's well described and logs are very useful. Besides maintaining many issues eat me all my free time... So even if all were not exactly the same, I suspect the root cause is identical , so just track this issue and add your new comments here.

Summary: Registration reliability tracking issue
Status: Accepted

[Anonymous]

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

Thank you for replying to this issue. It's very important one. What is the point of using a phone, that did not ring, when you need it...

The best way to troubleshoot is to watch events, when CSS sends its REGISTER requests to a SIP server. The SIP server could be any one, that is available from free offers. I do not have Asterisk, but I've installed free version of FreeSWITCH for WIndows. There is MSI installation package on their site, available to download.
"http://files.freeswitch.org/windows/installer/x86/"

After you run installer you may star using it immediately. Default configuration includes 20 extension numbers, ready for registering. Just configure one of those extensions in CSS, start FS and watch its log (or look at its running console). You can easily see when exactly CSS sends those REGISTER requests and when it stops doing that...  Let me know if you need any help with starting using FS.

You've mentioned that you don't reproduce that problem with your SIP provider. Yes, indeed, SIP provider doesn't give you a detailed log (at leas mine does not offer that). The only way to find the problem is to check current registration with them (if they give you a web console that shows current status) and that what I'm doing too. Time-to-time I see account in red - meaning unregistered... It's not a convenient way to watch. And that's why I'd recommend to install FreeSWITCH (or any other SIP server) locally and use it as a test tool.

I understand that it's not product for a pay. But I repeat again, if it fails to register (on a timely manner or stops doing that at all) - there is no big reason to use the phone... It's very serious issue.

[Anonymous]

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

@Yok: I agree that SIP Registration is critical: I would like to be assured that I am receiving my calls.  That is why I have a Linksys SPA2102, while I am experimenting with CSIPSIMPLE.  I recommend having a reliable backup like the SPA2102.

Let's show our support to Regis by being supportive and **courteous**.  This open source effort is based on free time and good will.  The reason that I use open source is that support is more likely to be around in the long term.  I support it by using it and (try to) provide useful feedback to the developer.

@Regis: We appreciate your efforts and look forward to helping you to make CSIPSIMPLE the best it can be.

[Anonymous]

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

@Regis
Have you had a chance to install FreeSWITCH to watch regularity of CSipSimple REGISTER requests? Any questions or suggestions? Do you need any help from my side?
I really need to get this important issue fixed...

[Anonymous]

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

Yes, I did a install of freeswitch on my linux. I watched and I never lose registration. (even by increasing log level I was able to see the 2 byte keep alive packets sent and it was very regular).

I'm still investigating however. I probably didn't spent enough time yet and it was on a very reliable wifi local connection. So I'll try different configuration.

I have a global idea of what could improve things. It would be to change the way the timer glue is done in pjsip. Currently it use a basic implementation (the one of linux), but this one is not really good for android cause on android cpu can go off.

The thing I did to workaround that was to rely on the fact keep alive is managed by csipsimple itself (that do things in java space and can use the android SDK to awake the phone when needed). But re-registration does not use this mechanism. So maybe on some device that have an aggressive policy regarding cpu sleeping re-registration can not be launched or delayed for long time.
The problem is that to solve this problem it means modifying significantly the way pjsip is integrated to android. Even better would be to take the approach that pjsip guys adopted for symbian which does not use worker threads -- it would also increase battery life.
But this should be done with care. I started to get a global overview of what was done in pjsip for symbian and I'll try to do something similar for android.

In the same time, I'll try to find out a solid repro scenario on my side so that I'll be more confidant with the fact something fix or not the issue ;).

I think that the device I'm currently testing on does not have a suffisant aggressive policy regarding sleeping of the CPU. I have other devices I can test on (not here cause I'm in holiday), so hopefully one of these will have this behavior (or maybe tweaking the cyanogenMod on this device)

I'll keep you in touch if I find something interesting or if there is something new to test. Sorry for the time it took to solve this issue. I understand that it's very annoying for a daily usage for those who need to be reachable.

[Anonymous]

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

@Regis
First of all, thank you for the detailed overview of the current status. I'm glad that you want to solve the problem and have some ideas on how to do that.

Do you have access to source code of SipDroid? I guess, it could help you to find out yet another way to use timer. From my past experience (I don't use it now, CSS is my primary client for this time), SipDroid was very regular with its registration.

I'm using a good WiFi connection too (most of the time). But I usually change my WiFi presence couple of times per day. And at that time, when I drive away from my WiFi spot, the connection easily become unstable and finally drops. I guess that could somehow contribute to instability of CSS (it's just a wild guess, of cause). I don't see strong correlation with that so far...

Another point here (why I see the instability and you don't) could be that I'm still using unmodified Android v.2.1 installed by manufacturer. I guess I have to update the OS, but before doing so I want to root the phone in order to make its full backup... I guess that could help (or may be it's just a wish thinking)... 

In any case, thank again and please keep us in touch.

[Anonymous]

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

I just want to add that i get the same problem.
Using the latest version 0.02-03 [r944] using VOIP.MS as a provider.
A manual reconnect is needed. All other SIP client are ok.

Thank you! This is the best VOIP app out there. Bria is good but eats 2 times more battery!

[Anonymous]

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

[r1005] that will be produced tonight will probably implements the new way to manage pjsip timers (using android SDK and being more agressive regarding cpu power).

It's maybe not very stable yet. Feedback welcome.

It also introduce an option in expert wizard mode to "Try to clean registers".

Many sip providers allows to have several registrations on their server with a limit.
For example it allows 3 registrations for an account.
In this case, csipsimple that run a mobile device, may consume more registrations that actually needed. For example, if the app is connected through wifi and lost connection it is not possible for the application to unregister. As consequence it will leave a dead registration on the server. And when wifi (or another connection) will come up again, it will create a new registration.
Unfortunately, the server on the other side can reach the limit of allowed registrations and just say forbidden (or other error code) for the new register.
The "Try to clean registers" is a workaround to address this problem. When it see an error when trying to register, it tries to unregister all registrations on the server (csipsimple's ones but also possibly registrations from other clients), and then try a fresh register.

Other point, as the new timers method is more agressive, if stun is activated you may observe bigger battery usage (even if I tried to limit this bad effect).

[Anonymous]

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

Issue 1014 has been merged into this issue.

[Anonymous]

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

@Regis,
Thank you for the new build. I'll install the latest [r1006] and watch it.

[Anonymous]

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

I am going to give this a try also....thanks for continuing to work on this.

[Anonymous]

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

FYI I gave 1009 a try and immediately it disconnected and would not let me
register again. Even deleting and then adding the account again does not
help it.

[Anonymous]

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

So far, it has fixed my problem. The connection cleanup seems to work

[Anonymous]

Originally posted by: a...@addi.ch

I do still have problems. After a while I lose always my registration. Attached some logs with [r1009]. First two without "Try to clean registers", last with "Try to clean registers" activated.

[Anonymous]

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

Today I've noticed, that CSS shows, that it's registered, while SIP server indicates, that it's not. CSS stopped sending REGISTER requests many hours ago (in the middle of the night). I've made a call from CSS in that state - it worked well. Tried to receive call and it fails, or course. Turning off/on account in "Accounts" page helped to restore registration status.

The problem occurred with [r1006]. I'll try the new [r1013].

[Anonymous]

Originally posted by: m...@nilsson.nl

For me it's also still losing connection once in a while (HTC Desire), it seems less though but still not reliable. I could post a log if you need it?

[Anonymous]

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

Issue 1263 has been merged into this issue.

[Anonymous]

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

Ok, besides the registration problems already pointed out by other users here, the most prevalent issue with my Defy is that Gingerbread sinply 'dehidrates' CSS' process from its usual 10+MB state down to a 2MB one, where all SIP connections are lost. And the weirdest thing: only when I'm under Wi-Fi! Under mobile data, everything seems to work. This is incredible! How come Gingerbread closes communication applications? They are too important to be killed! Regis, is there anything you can do about it? I already checked the 'partial wake lock', as well as the 'High perfs' settings, to no avail.

Thanks, anyway.