Registration reliability tracking issue

[GoogleCodeExporter]

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="http://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="http://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.

Original issue reported on code.google.com by yok...@gmail.com on 9 Jul 2011 at 8:56

[GoogleCodeExporter]

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.

Original comment by yok...@gmail.com on 12 Jul 2011 at 6:46

[GoogleCodeExporter]

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... 

Original comment by yok...@gmail.com on 21 Jul 2011 at 5:18

[GoogleCodeExporter]

Issue 1163 has been merged into this issue.

Original comment by r3gis...@gmail.com on 21 Jul 2011 at 10:18

[GoogleCodeExporter]

Issue 912 has been merged into this issue.

Original comment by r3gis...@gmail.com on 21 Jul 2011 at 10:25

[GoogleCodeExporter]

Issue 999 has been merged into this issue.

Original comment by r3gis...@gmail.com on 21 Jul 2011 at 10:32

[GoogleCodeExporter]

Issue 1072 has been merged into this issue.

Original comment by r3gis...@gmail.com on 21 Jul 2011 at 10:58

[GoogleCodeExporter]

Issue 859 has been merged into this issue.

Original comment by r3gis...@gmail.com on 21 Jul 2011 at 10:59

[GoogleCodeExporter]

@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.

Original comment by r3gis...@gmail.com on 21 Jul 2011 at 11:11

• Changed title: Registration reliability tracking issue
• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by yok...@gmail.com on 22 Jul 2011 at 3:05

[GoogleCodeExporter]

@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.

Original comment by raymond....@gmail.com on 22 Jul 2011 at 3:45

[GoogleCodeExporter]

@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...

Original comment by yok...@gmail.com on 28 Jul 2011 at 7:59

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 28 Jul 2011 at 10:52

[GoogleCodeExporter]

@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.

Original comment by yok...@gmail.com on 28 Jul 2011 at 11:34

[GoogleCodeExporter]

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!

Original comment by patrick....@gmail.com on 13 Aug 2011 at 12:20

[GoogleCodeExporter]

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).

Original comment by r3gis...@gmail.com on 17 Aug 2011 at 10:03

[GoogleCodeExporter]

Issue 1014 has been merged into this issue.

Original comment by r3gis...@gmail.com on 17 Aug 2011 at 10:08

[GoogleCodeExporter]

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

Original comment by yok...@gmail.com on 18 Aug 2011 at 10:00

[GoogleCodeExporter]

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

Original comment by steve...@gmail.com on 23 Aug 2011 at 7:57

[GoogleCodeExporter]

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.

Original comment by steve...@gmail.com on 23 Aug 2011 at 8:28

[GoogleCodeExporter]

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

Original comment by patrick....@gmail.com on 23 Aug 2011 at 8:42

[GoogleCodeExporter]

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.

Original comment by a...@addi.ch on 24 Aug 2011 at 5:03

Attachments:

• logs_08-24-11_173507.txt.zip
• logs_08-24-11_122701.txt.zip
• logs_08-24-11_185953.txt.zip

[GoogleCodeExporter]

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.

Original comment by yok...@gmail.com on 25 Aug 2011 at 8:34

[GoogleCodeExporter]

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?

Original comment by m...@nilsson.nl on 29 Aug 2011 at 7:27

[GoogleCodeExporter]

Issue 1263 has been merged into this issue.

Original comment by r3gis...@gmail.com on 8 Sep 2011 at 9:22

[GoogleCodeExporter]

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.

Original comment by casou...@gmail.com on 21 Sep 2011 at 5:04

[GoogleCodeExporter]

Issue 1117 has been merged into this issue.

Original comment by r3gis...@gmail.com on 25 Sep 2011 at 9:08

[GoogleCodeExporter]

Hello,
These days csipsimple started registration issues again. I will send a log now. 
It looses registration and does not try to re-register again though I have set 
the option "try to clean registers" Sometimes it freezes at "green". I mean it 
shows registered but it is actually not and it does not try to re-register if I 
"push" the button on and off again. Sometimes it freezes at "orange" -> Not 
Registered. The only way to fix this is to restart the application by killing 
it. Disconnect does not work. It will be nice if you can put an option "try to 
register forever" or something similar.
I also saw another unusual activity I do not know if it is related to this and 
I apologize if I wrote it in a wrong thread. When I hang up it does not remove 
the "vibration only" symbol and when I try the volume up button it shows me 
that I'm changing the call volume as I'm still in a call. That started a few 
revision ago. It happens only sometimes. Again the only solution is to kill the 
application and start it again.

Best Regards,
Asen

Original comment by amis...@gmail.com on 29 Sep 2011 at 12:49

Attachments:

• logs_09-29-11_134737.txt

[GoogleCodeExporter]

Hi,

Same problem as you Asen, I opened an issue yesterday regarding that
http://code.google.com/p/csipsimple/issues/detail?id=1295 (merge them maybe?)
I haven't found anyone else experiencing that issue, and it's hard to reproduce 
it. Asen, are you using some plugin like Betamax plugin? I don't know if it can 
be related.

For your second issue (vibration only), I didn't notice that as I'm almost 
always in vibration mode, but I'll make tests and keep you updated so that we 
will see if there is a link between these issues.

Regards,

eD

Original comment by o...@netfusion.fr on 29 Sep 2011 at 3:43

[GoogleCodeExporter]

No I do not have any plugins installed.

Original comment by amis...@gmail.com on 29 Sep 2011 at 4:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm using CSS (r944) + voip.ms on a LG Optimus One (android 2.2.1)

I had the same issue as "1. Time-to-time CSS looses registration .." but iny in 
wifi.

Until I realise that Wifi is switch off when the screen goes black (sleep mode 
...). I don't know if this is the same issue for you .... To force android to 
keep the wifi ON in sleep mode: under android parameter, in wifi press menu 
button, in advanced menu pops up, set your wifi sleep policy to NEVER.

With this setting, i don't lose registation with voip.ms (not extensive test 
done yet ...).

Regards,
Nico.
PS: thx r3gis for your outstanding app !

Original comment by nicolas....@gmail.com on 18 Oct 2011 at 2:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Registration lost in 3G mode

In WIFI, It seems to work: registration is OK (with the sleep policy to NEVER 
cut wifi in the android parameter), heart beat (40s) , time to register (600s) 
...

BUT in 3G, with exactly same paremeters (heartbeat, time to registerer ...), I 
always lost the registration after several minutes.

Do you know if it's possible that the phone fall to a Deep Sleep Mode and then 
cut the 3G connexion ? Is there a 

I don't think it's a "pure" CSS issue, but a combinaison of factor between CSS 
and Android OS.

How could I debug this issue: the log (in help menu) only give me the 
registration:
Based on the GPL CSipSimple version : 0.02-03 r944
Here are important informations about Device :
android.os.Build.BOARD : thunderg
android.os.Build.BRAND : LGE
android.os.Build.DEVICE : thunderg
android.os.Build.ID : FRG83
android.os.Build.MODEL : LG-P500h
android.os.Build.PRODUCT : thunderg
android.os.Build.TAGS : release-keys
android.os.Build.VERSION.INCREMENTAL : eng.nikech.choi.20110126.134422
android.os.Build.VERSION.RELEASE : 2.2.1
android.os.Build.VERSION.SDK : 8

See the attached file below

I hope I (or the crowd) can find a solution for this problem, because it'a a 
stopper for me if can't keep a registration active (I want to use CSS for 
incoming call, without a solid registration process it's useless)

Nico.
PS: I'm using CSS (r944) + voip.ms on a LG Optimus One (android 2.2.1)

Original comment by nicolas....@gmail.com on 19 Oct 2011 at 2:29

Attachments:

• logs_10-18-11_221413.txt

[GoogleCodeExporter]

Just repeting myself ... the registration pb occures only in 3G

See below log file (I just edited the file to remove personnal information):
where I lost the connection ...
The last one is in "verbeux" mode

Nico.
PS: I will do an other try with a lock CPU ... (even if it drain battery)

Original comment by nicolas....@gmail.com on 19 Oct 2011 at 1:27

Attachments:

• logs_10-18-11_221413.txt
• logs_10-19-11_091827.txt

[GoogleCodeExporter]

@nicolas : it would be interesting to test with nightly builds instead of the 
market version. I did a lot of changes to lock cpu only when a timer has to be 
fired. So it should reduce cpu impact and increase reliablity of the 
connection. Still the app is not stable enough to be released I think, and 
there is also other use case where re-registration get problems (mainly due to 
stun/ice I think).
But it could be a good base to test on since r944 is pretty outdated compared 
to nightly build on this issue.

Original comment by r3gis...@gmail.com on 19 Oct 2011 at 1:31

[GoogleCodeExporter]

Thx r3gis to your response. How do you manage to give your time for this 
opensource project: do you get payedfor ?. If i can keep the registration ON in 
3G, you could count on a donation (this will save me so much money to use 
CSipSimple+voip.ms+3G instead of my Telco Voice plan !)

FYI, I have the same pb in 3G with:
 - r944
 - "lock CPU/Utiliser le verrouillage du CPU" activate
 - STUN activate (stun.counterpath.com)
 - ICE: not activated !
 - Allow UDP and TCP (just in case ;-)
 - heartbeat 40s in mobile mode

See log file below

I begin an other test (with 944) by activating ICE (not sur what it is but if 
it's better for Nat traversal it could help) ... and let you know the results
Nico.

PS:  I will try the nighty build later and let you know the results about 
registration.

Original comment by nicolas....@gmail.com on 19 Oct 2011 at 2:17

Attachments:

• logs_10-19-11_095930.txt

[GoogleCodeExporter]

Same pb with ICE activated ...

Original comment by nicolas....@gmail.com on 19 Oct 2011 at 2:24

[GoogleCodeExporter]

I currently use r1050, and even with WiFi standby set to "never" CSS always 
loses registration after a while when the phone (SGS2 w/stock Android 2.3.3) is 
not in use.

This happens when connected via WiFi. One of my SIP servers is actually my WiFi 
router (a Fritz!Box 7170 by AVM) which is in the same WiFi network as the phone 
so WAN disruptions can be ruled out in this case.

But after a while the icons and entries (for all SIP registrations) in the 
status pull-down menu simply vanish, as if CSS just terminates for some reason, 
and the phone doesn't react to incoming SIP calls any more.

When I start CSS manually it registers again and works as expected. When I 
leave CSS and stop using the phone the registration is gone again after a 
while, ad infinitum.

My two cents.

Regards,

Uwe

Original comment by uwe.doer...@gmail.com on 19 Oct 2011 at 3:24

[GoogleCodeExporter]

I'm experiencing the same issue. This could be the interesting part of the logs:

I/ActivityManager( 2706): No longer want com.csipsimple:sipStack (pid 11853): 
hidden #26
W/ActivityManager( 2706): Scheduling restart of crashed service 
com.csipsimple/.service.SipService in 5000ms
D/dalvikvm(16510): GC_EXPLICIT freed 44K, 52% free 2817K/5831K, external 0K/0K, 
paused 82ms
I/ActivityManager( 2706): Start proc com.csipsimple:sipStack for service 
com.csipsimple/.service.SipService: pid=18671 uid=10114 gids={3003, 3002, 1007, 
1015}
(I have sent the full logs to developers at csipsimple )

Even if it seems that the service is restarting, my accounts are no longer 
registered.
I notice that issue when I stay connected to the same WiFi access point for 
30/40 mins without making any SIP or GSM calls. CSS still runs anyway (only the 
sipStack hangs?).

I saw on a that page that a developer experienced the same issue with his 
Android app:
http://stackoverflow.com/questions/3297204/android-service-killed-with-no-longer
-want-how-to-restart-it

His problem was fixed by using startForeground() but as I'm not a developer I 
can't give you more information about in which context to use it. I hope it 
will help anyway.

My conf: Samsung Galaxy S2 with android 2.3.5 and r1051.

Thanks.

Original comment by o...@netfusion.fr on 19 Oct 2011 at 4:29

[GoogleCodeExporter]

@edoouard : very interesting point. I'll give it a try. Seems to be harmless 
and only better :) 
So it would be interesting to add this feature of android to tell android that 
the service is important and should not be killed when memory is low.

I commit that as r1054.

Original comment by r3gis...@gmail.com on 19 Oct 2011 at 8:52

[GoogleCodeExporter]

Glad that you'll tell Android that CSS is too important to be closed, Regis. 
That was my point in comment 26, above. For some time now, I used Titanium 
Backup to convert CSS to act as a system application, but it doesn't quite 
solve the issue. 

Eagerly waiting for r1054, then.

Thanks, anyway.

Original comment by casou...@gmail.com on 19 Oct 2011 at 9:24

[GoogleCodeExporter]

I tried r1055 (from last night) this morning but it doesn't register at all. 
However, r1051 doesn't work either! I had to go back to r1050, which I used 
before, in order to get CSS to register again. It wouldn't do so even when I 
started CSS manually. The accounts stayed at status yellow, and CSS apparently 
didn't even try to register for some reason.

As to the changes in r1051, I don't use G722. The minimum set of codecs I tried 
with is GSM, PCMA and PCMU, in that order. To no avail. So it is probably the 
change at line 300 that breaks things at least on my SGS2. The line was 
commented out before, perhaps for a good reason.

So once this is fixed I'm ready to try out the change made in r1054.

Original comment by uwe.doer...@gmail.com on 20 Oct 2011 at 8:03

[GoogleCodeExporter]

@uwe : I commented out the line 300 cause was useless previously - due to the 
fact iLBC is now available for all device since webRTC implementation is used - 
And I now re-introduced it cause I need it for g722 testing. If I had a good 
reason for commenting it out, I'd have removed the line or added a comment 
around it to explain why it should not be used ;). 
Besides, if you are just upgrading from r1050 to r1051 this code should not be 
executed at all. 

So the problem is somewhere else ;). 
The only other thing that can change excepted my code is the webRTC code that 
directly comes from google and sounds they broke my builds.
I'll check that and give you feedback, but you're right r1055 at least is 
broken - when you see that the build size is only 2.3Mo it means that the 
native library was not built in, and there is no chance this build works ;).

Thanks for the report.

Original comment by r3gis...@gmail.com on 20 Oct 2011 at 8:11

[GoogleCodeExporter]

r1058 just produced. It should be better :)

Original comment by r3gis...@gmail.com on 20 Oct 2011 at 11:07

[GoogleCodeExporter]

Already testing it. Registration of my SIP accounts went smoothly. Now checking 
over some time to see if it will be shut down by Android memory management or 
not...

Original comment by casou...@gmail.com on 20 Oct 2011 at 11:17

[GoogleCodeExporter]

Thanks to Régis (who never sleeps, you are allowed to take a nap now). Trying 
the 1058, I'll post my feedback asap.

Original comment by o...@netfusion.fr on 20 Oct 2011 at 11:24

[GoogleCodeExporter]

Regarding the modifications you've done to tell Android not to kill CSS, I can 
tell you that after almost 4 hours, so far, so good. Besides, what makes your 
efforts even brighter, I tested r1058 on Gingerbread, which happens to have the 
most strict memory management among all Android builds. Congratulations, Regis! 
Thanks a lot for your hard work!

Original comment by casou...@gmail.com on 20 Oct 2011 at 2:46

[GoogleCodeExporter]

You should congratulate edouard for the hint ;).

BTW, I'll have a closer look to issue 1337 and 1333 cause sounds very annoying. 
(I'll also try to release a ICS theme soon ;) ).

Original comment by r3gis...@gmail.com on 20 Oct 2011 at 3:35

[GoogleCodeExporter]

I have been testing r1058 on both Honeycomb 3.2.2 and Gingerbread 2.3.4 and no 
disconnects yet. This is clearly the longest I have stayed registered with CSS. 
Next I am going to test changing from 3g to Wifi and back to see if I 
re-register.

Original comment by steve...@gmail.com on 20 Oct 2011 at 5:08