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]

Seems that the problem is solved for me too! No disconnection. Great job Régis.

Original comment by o...@netfusion.fr on 20 Oct 2011 at 7:29

[GoogleCodeExporter]

Has anyone tested successfully on Gbread 2.3.4? I am not able to register at
all using my Droid 3. Using my Xoom tablet works just fine.

Original comment by steve...@gmail.com on 20 Oct 2011 at 11:16

[GoogleCodeExporter]

I've installed r1058 today and soon got the problem. CSS run for several hours. 
and I moved form one WiFi location to another. When I arrived to the last 
location I've noticed that CSS is not registered (there is no its icon in top 
bar). I waited for a long time - no luck. There is no attempts to register at 
all. Checked with OSMonitor and have noticed, that there are two processes 
running:
1. com.csipsimple. Start time: 15:53 (time when new version of CSS was launched)
2. com.sipsimple:sipStack. Start time: 18:30 (time when I arrived to new WiFi 
location)

I suppose that both processes have to have the same start time. Right? If so, 
why the second one indicates its start time approximately at the time, when I 
arrived to the last WiFi location and discovered that it's not registered now? 
Does that mean that sipStack was down (crashed) and then restarted?

And the second question. Do you have a procedure to restore inter-process 
communication channel between those two processes in case when one is restarted 
(sipStack)? If there is no such specific procedure (reuse the old connection 
channel) - it could be the reason why CSS is not registered at that time. 
Please verify that it's working - intentionally kill/crash sipStack and restart 
it back again and see if CSS will register itself. If there is no such 
procedure and you're not going to implement it for whatever reason - the only 
solution is to kill main CSS process too and then restart them both... Keeping 
CSS running while it's not even try to register itself is not a solution.

Original comment by yok...@gmail.com on 21 Oct 2011 at 2:42

[GoogleCodeExporter]

@yok : can you get the logs from the crash?

About restart stuff, actually in one case you're right, but most of the time, 
that's not the way it works.
sipStack process is about the sip service only and the root process is about 
the UI. I've separated the two process cause it could help with memory 
management. 
However, it does not changes the way things works : the sip service is 
restarted when connection changes. (So it could explain why the start time is 
different) and it is stopped when there is no connection available anymore. It 
is automatically restarted when networks changes (independantly of the UI 
thread) and it is also started when the UI thread explicetly ask for a 
start/restart. (when you go in settings and go back and when you start the 
dialer activity).

It was already the case in previous version but was not seen by user since 
everything was in the same process.

The only case it can behaves the way you fear is when :
 - the app is configured to run only for outgoing.
 - the sip service crashes while the dialer UI is suspended (you quit it using home instead of back button or you didn't quit it at all).
 -> at this point sip service can be not started when you resume the dialer UI. (I'll fix that by checking state on resume).
On all other case the service process ~should~ be independant of the other 
process - and that's safer all the more so as, csipsimple can be used in plugin 
mode by other apps without having to start csipsimple UI at all.

However, possible that it crashed in your case : reason why I'd like to get 
logs cause else I can't guess what really happened. 
I've already seen some crashed with my new timer implementation in pjsip. I'll 
investigate that in next days, but if you have logs it can be very helpful for 
me.

It is also possible that there is something completely different that make the 
sipStack process not restarting correctly (something that block it somewhere). 
For this reason too, logs can help me to understand what's happening.
But anyway the goal is not to link it to the UI process. It should be 
independant. 

@steve : weird that it does not work on your gingerbread device, I made most of 
my tests on 2.3.x devices. Can you collect and send me some logs so that I can 
see why it does not register. 

Thx to all for your tests and ideas, it is very valuable :D !

Original comment by r3gis...@gmail.com on 21 Oct 2011 at 7:05

[GoogleCodeExporter]

For the sake of completeness, it works now for me, too (SGS2 w/stock 2.3.3). 
And so far, it also re-registered when I changed networks. I configured it for 
WiFi mode only, though, because SIP unfortunately doesn't work via 3G with the 
telco provider I use.

Regards,

Uwe

Original comment by uwe.doer...@gmail.com on 21 Oct 2011 at 7:35

[GoogleCodeExporter]

Hello,
I would like to thank Regis for the great work. I would say that it works much 
more better for me too. I still experience some issue with the registration but 
I think it is due to something different. For a couple of times I see the usual 
error 403 Forbidden which Regis fixed a long time ago. But this time it just 
keeps showing the error and not registering (but still trying). I have to go to 
settings and than go back and everything works fine from this point on. 
(without changing anything). The other thing is that sometimes the icon 
disappears but the sip is still connected because I can make and receive calls. 
The problem is that I cannot get logs because I do not know in which cases this 
happens. It may happen once a week or everyday. There isn't any pattern.

Original comment by amis...@gmail.com on 21 Oct 2011 at 7:58

[GoogleCodeExporter]

A couple of things:

1) Can someone tell me how to get the logs, as I want to be able to provide 
this from my Droid 3.
2) Is there anything that CSS does to register that is different than say 
Sipdroid?

The reason for question 2 is that I can register fine with Sipdroid on my Droid 
3 but I cannot get CSS to register. I am wondering if I am missing something 
that CSS is looking for.

Thanks,
Steve

Original comment by steve...@gmail.com on 21 Oct 2011 at 4:11

[GoogleCodeExporter]

@steve : To get logs : http://code.google.com/p/csipsimple/wiki/HowToCollectLogs

It does nothing really different from sipdroid. The sip stack is slightly 
different but it's still SIP. *HOWEVER* I do not recommand to use two sip apps 
at the same time on one phone for 3 reasons. 
First, a sip application listen on TCP/UDP ports of the phone. If the two 
application listen on same port, it will just break one of the two apps. In 
CSipSimple, by default, it choose a random free port so should be fine. But if 
you changed it to 5060 or are migrating from an older version it may overlap 
with sipdroid that force 5060.
The second point, is that many sip providers only allow *ONE* sip client at a 
time to be registered on one sip account. So if you are registered somewhere 
else, you may break the other registration.
The last point is about audio resources, apps may lock audio resources and 
prevent other app to get access to audio layer.

Else, I've just fixed a bug with timers that may explain crashes observed in 
latests versions - espacially on network changes. 
It will be produced automatically tonight. I'm still trying to debug a problem 
with reset of settings. If you observe this behavior I'm interested by logs :). 
-symptom is that you see the first setting screen when starting dialer while 
you have already configured that once.

Original comment by r3gis...@gmail.com on 21 Oct 2011 at 4:41

[GoogleCodeExporter]

I just replicated the registration issue on my Droid 3 and sent you the logs 
via email. If you need anything else just drop a note. And yes I only run one 
app at a time...lol.

Original comment by steve...@gmail.com on 21 Oct 2011 at 5:19

[GoogleCodeExporter]

Regis, I've noticed the the bug you have just described, about easy 
configuration screen coming up with default values, even after it had been 
configured before. In one occasion, I roamed from Wi-Fi to mobile data, and I 
noticed that CSS hadn't registered my accounts for many minutes. Then, I 
checked easy configuration, and 'I'm allowed to use mobile' was unchecked. I'm 
pretty sure I had checked that configuration before. It's the first thing I do 
after installing CSS.

Original comment by casou...@gmail.com on 21 Oct 2011 at 6:33

[GoogleCodeExporter]

@casou : yes, I think you experimented the issue. It is probably also the root 
of issue 1337 also.
I'm producing a build that at least should avoid some crash cases, maybe it 
will help with this problem too. I noticed that after a crash so maybe it's 
linked.

Maybe it will also help with Steven's problem, even if in his case sounds the 
server does not reply at all.
@steven : are you sure that your mobile data connection allow you to do sip? 
Sometimes some mobile carrier allow sip only under some antennas. 
In fact, I never see reply from the sip server in logs, just like if it did 
never receive the packets sent by the app. This occurs most of the time when 
the carrier has a firewall or some equipement to avoid SIP over mobile data. 
For example, here, in France 2 out of 3 carrier blocks SIP over mobile data. 
Or, it could also be linked to what I fixed in my latest commit, but if so, I 
think that it would be more random.

Original comment by r3gis...@gmail.com on 21 Oct 2011 at 7:47

[GoogleCodeExporter]

Both my Xoom and Droid 3 are on Verizon Wireless, so I definitely know this is 
not carrier related. Second I can put Sipdroid on the same Droid 3 and it works 
just fine. I have a couple more items I want to try on my Droid 3 and will 
communicate results back.

Original comment by steve...@gmail.com on 21 Oct 2011 at 7:52

[GoogleCodeExporter]

Regis, r1061, just uploaded, contains the changes you pointed out above?

Original comment by casou...@gmail.com on 21 Oct 2011 at 8:58

[GoogleCodeExporter]

Yes. I launched a manual build with these changes. 
I did tests over the afternoon on one device with this change and sounds better 
regarding crashes at least. I'll try to do more tests tomorrow in order to make 
sure my changes of the week does not break something else. Do not hesitate to 
share if you notice something wrong :)

Original comment by r3gis...@gmail.com on 21 Oct 2011 at 9:24

[GoogleCodeExporter]

Already testing it too...

Original comment by casou...@gmail.com on 21 Oct 2011 at 9:25

[GoogleCodeExporter]

OK so my initial test results with 1061 are as follows:

1) I can register successfully on my Droid 3 with 1061....yea!
2) I selected Always Available in the initial config and hit save, but this is 
not being saved truly. In going back into the Easy Config screen Available on 
WiFi was selected. I had to re-select Always Available and hit save one more 
time for it to be truly saved.

I will do more 3g to Wifi and back tests once I am home, but wanted to get this 
out to you while it was fresh in my mind on the train.

Original comment by steve...@gmail.com on 21 Oct 2011 at 9:53

[GoogleCodeExporter]

Omg, I've got that odd condition overnight, where the icon vanishes from the 
status bar, but all my accounts are shown  green, but CSS is acting like a 
ghost. I mean, it responds to taps, but when I tap on an account icon to 
deactivate it, the bar beneath the icon turns grey, but its name is kept green 
(registered). I had to kill CSS, to get rid of that situation. Well, its dock 
is beside my bed, where both wifi and mobile data coverage are poor.

Original comment by casou...@gmail.com on 22 Oct 2011 at 10:28

[GoogleCodeExporter]

Wifi to 3G and back to Wifi yield no registration issues on 1061 so far. I have 
left CSS up all night without issue. One thing I might be seeing is very high 
battery usage on calls. I am going to keep an eye out for that.

Is there a document that details all the options and what they do?

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

[GoogleCodeExporter]

I still experience issues but I do not know in which cases. But I think it is 
when there is poor reception something crashes the sip service. The problem is 
that in this moment when I want to start logging so I can send an actual log of 
what is happening I guess the sip service restarts and registers. Is there 
anyway I can collect a log so I can send it to you Regis?

Original comment by amis...@gmail.com on 26 Oct 2011 at 11:53

[GoogleCodeExporter]

I have the same problem Amis.  What I do is tell Csip to start recording logs 
before the problem occurs.  Then when it fails to register, logs have built up 
of the problem and even though it registers when I open csip, I can still send 
the logs that have accumulated.

Registration is a whole lot better now.  The problem has only happened once 
since 1058.

Cheers.

Original comment by kro...@gmail.com on 26 Oct 2011 at 7:44

[GoogleCodeExporter]

I finally was able to collect logs so I sent them a minute ago. 

Original comment by amis...@gmail.com on 30 Oct 2011 at 3:09

[GoogleCodeExporter]

Issue 1363 has been merged into this issue.

Original comment by r3gis...@gmail.com on 5 Nov 2011 at 10:59

[GoogleCodeExporter]

Issue 1362 has been merged into this issue.

Original comment by r3gis...@gmail.com on 5 Nov 2011 at 11:06

[GoogleCodeExporter]

r1090 was shut down by Android overnight. In the morning there was just a 
dehidrated 2MB process running. I'm sticking to the last stable version for me, 
r1075.

Original comment by casou...@gmail.com on 8 Nov 2011 at 1:36

[GoogleCodeExporter]

Yes, webrtc changes their code, which broke csipsimple builds. I'm doing a 
manual build to replace this one. :)

Original comment by r3gis...@gmail.com on 9 Nov 2011 at 10:12

[GoogleCodeExporter]

r1094 seems to be pretty stable, regarding Android's memory management. It is 
up for a couple of hours now, without being shut down by Android even once. 
Good job, Regis!

Original comment by casou...@gmail.com on 9 Nov 2011 at 8:44

[GoogleCodeExporter]

Issue 304 has been merged into this issue.

Original comment by r3gis...@gmail.com on 10 Nov 2011 at 10:46

[GoogleCodeExporter]

r1094 seems to be very stable on my Motorola Droid3. Any major changes between 
1094 and 1096. I noticed that the build size is 1 meg smaller in 1095 and 1096.

Original comment by steve...@gmail.com on 12 Nov 2011 at 4:42

[GoogleCodeExporter]

Mmmh, sounds the webRTC has gain broken nightly builds :/.
I'll fix that right now, thanks for reporting.

Original comment by r3gis...@gmail.com on 12 Nov 2011 at 4:51

[GoogleCodeExporter]

Actually it's half broken, it should work fine but does not contain optimized 
armv7a lib :)

Original comment by r3gis...@gmail.com on 12 Nov 2011 at 4:53

[GoogleCodeExporter]

Fixed. Between 1094 and 1096, except webRTC changes (made by google), there is 
just minor changes on wizards.
I think that I'll do the stable release on the market tomorrow. I still have to 
make sure it does not bring regression on andorid 1.5 and 1.6 devices. But 
that's  on the good way :).

Original comment by r3gis...@gmail.com on 12 Nov 2011 at 5:23

• Changed state: NextRelease

[GoogleCodeExporter]

Running the latest build r1235 and got the old annoying problem - CSS doesn't 
want to send any registration requests at all.

Scenario:
1) Connected to LAN at home - CSS is registered. 2) Went to another WiFi spot - 
CSS is registered, I've made couple of test calls - everything is OK. 3) 
Returned back to home LAN - CSS doesn't send any registration requests. I 
started CSS's log, waited for 1h - nothing. I've turned WiFi off on the phone 
and then turned it back on - nothing again. Stopped the log and I don't see any 
messages, associated with PJSUA. 

Is PJSUA module somehow stuck? And for how long? Waited for the nest 2h and 
wrote this post... I guess it's stuck indefinitely. "Account" shows yellow bar 
and message "Inactive" with account, that should be registered by now.

Why PJSUA doesn't react on system notifications like this one (from the log):
D/ConnectivityService(   84): handleConnect() networkinfo=NetworkInfo: type: 
WIFI[], state: CONNECTED/CONNECTED

My guess - the problem is with PJSUA, that can't survive frequent CONNECTED / 
DISCONNECTED notifications. May be it has sent some request to SIP server and 
just waits for a reply, which, as it may wrongly expect, will always come back. 
And it doesn't... In any case, it should _always_ reset all its status, when it 
gets DISCONNECTED / CONNECTED message(s) from the OS. That's the only way to 
make it work more or less reliable.

Original comment by yok...@gmail.com on 23 Jan 2012 at 3:54

[GoogleCodeExporter]

I've got the similar problem today too. But now it happened in a remote 
hotspot. CSS was registered for a while. But eventually, when I tried to make a 
test call - there was no registration anymore. Any attempts to restore 
registration (by toggling account status) failed. Since that account always 
stayed in "Inactive" state. Tried to exit CSS (using Menu |Disconnect action) 
and it did not helped at all. My guess is - the stuck module is still in memory 
(despite my requests to exit the program several times). There is only one 
solution - to kill the program with a third party tool :(

Original comment by yok...@gmail.com on 24 Jan 2012 at 4:26

[GoogleCodeExporter]

Same here.  May be stun related...

Original comment by kro...@gmail.com on 24 Jan 2012 at 7:13

[GoogleCodeExporter]

Today got similar story again. On remote hotspot CSS was registered. I've 
started log, made successful test call. But when I returned home - there is no 
registration. Tried to "Disconnect" option - it did not work. I had to kill 
"com.csipsimple:sipStack" process with third party tool. Only after that CSS 
got its registration back. Log shows no line mentioned "pjsip" at all... 

How it's supposed to debug the issue, if there is no data in the log??? 

Talking about Android's log - the guys who developed it have absolutely no idea 
what are they doing and why. There is no time stamps, almost no meaningful 
messages, just a dump of a garbage, repeating the same meaningless lines again 
and again... Need an example? Here is just one line (repeated 104 times per the 
log):
"I/global  (  525): Default buffer size used in BufferedReader constructor. It 
would be better to be explicit if an 8k-char buffer is required." 

Sorry for the frustration about the Android's log, but how to find out why the 
process "com.csipsimple:sipStack" is getting stuck and how to make it start 
running again without applying a third party tools?

Original comment by yok...@gmail.com on 25 Jan 2012 at 3:49

[GoogleCodeExporter]

If the goal of r1241 change ("Fixes force close when the app is disconnected") 
was to make the "Disconnect" work, then I may report, that I don't see any 
change at all. Running the latest r1242 I click on "Disconnect" and two 
processes still run in memory... And CSS still stuck in its weird state, when 
it doesn't want to register to SIP servers anymore. Accounts are still in 
"Inactive" state indefinitely. I see it every day. The only solution is to kill 
one of the two processes running with a third party tool:
1. com.csipsimple - killing this process doesn't help
2. com.csipsimple:sipStack - killing this process always helps

Why do not kill the 2nd process when I ask CSS to "Disconnect"? It will 
certainly reset the program. And the next time I start it - it will register my 
accounts without any problems.

Original comment by yok...@gmail.com on 2 Feb 2012 at 4:22

[GoogleCodeExporter]

During the past week I'm running Sipdroid v2.4, instead of CSS. And you know 
what? In the same environment, under the very same conditions, it always works! 
As soon as I see "Connected" icon in notification bar, I start to see the big 
green dot, indicating that Sipdroid is registered and ready to receive / make 
calls. 

Looking at the development of this important issue, I'm not confident, that 
using PJSIP library was a right decision. It is not reliable and it looks like 
no one cares. Sipdroid is a way much better from the reliability perspective. 
Why not to use in CSS SIP library used by Sipdroind? 

I think until this major problem with CSS will get fixed, I better run Sipdroid 
as my SIP phone and will use CSS only at occasions, just as a test tool... :(

Original comment by ozo....@gmail.com on 7 Feb 2012 at 5:13

[GoogleCodeExporter]

@ozo :

1st point : I really care about this problem. 

2nd point : I develop CSipSimple on my free time night and week ends. It's a 
project I did for myself first and released to share with any kind people that 
want to play and contribute with it. Maybe it sounds to you something 
professional, but it's not. It's made of feedback and help of users. Sipdroid 
is developed by the company behind pbxes.org, and is very linked to their 
service. (and there is even bug they maintain to keep compatibility with their 
server). There is team working all day long on their product.

3rd point : Nightly builds available here 
(http://nightlies.csipsimple.com/trunk/) are as their name suggest nightly 
builds that reflects the current development status. As the rest of the project 
it's opened to everyone so that users can play with it. It sometimes helps to 
solve issues because it contains bug fixes, but there is also regressions 
sometimes.

4th point : You seems to have "good" technical advice about which sip stack is 
the best... Did you think about contributing the opensource project? Any 
contribution is welcome, and one that would fix this issue will be very welcome 
;).

5th point : I'm not sure your advise is very good about sip stack. I have 
considered integrating imsdroid stack and linphone stack but never sipdroid's 
one (actually it's not a stack since many things are inside the android part). 
You should have a look to imsdroid and linphone which are very good community 
driven opensource projects. I don't force anybody to use CSipSimple. It can 
becomes better if community raise. I hope so because many sip provider has 
forks based on csipsimple so maybe one of them will contribute some fix for 
this.

6th point : This issue is absolutely not linked to pjsip but to my own code. 
Every stack needs a glue to be ported to a platform. And this problem is linked 
to my glue. Other professional apps such as Bria use pjsip too. If I had a full 
day to work on csipsimple probably it would be much more better, but I have 
only 1 or 2 hours a day dispatched on my free time. 

To conclude, of course if you are looking for some "professional" app, 
csipsimple is absolutely not the right project. You should ignore it instead of 
making me depressed seeing guys spit on my work. If you are looking for a 
project community driven and where contribution are welcome and made for all 
users -not only the one of one sip provider- by users it's the right place 
however ;). 

I don't mean to be rude, I just want to made clear the "goal" of the project 
and try to make understand that in this kind of project only constructive 
feedback is welcome. Those who spit on developers that just wants to contribute 
something to users are not welcome. If it was a professional app, I would find 
less chocking to see such feedback because there is a whole support team, 
validation team and so on that could reply, investigate and try to report to 
developer valuable information to improve the software. But here, all time I 
loose trying to explain goal of the project and giving feedback on my 
development progress is time that I do not spend improving the software. The 
only thing you can do is make me think that I'm spending my time for guys that 
do not understand the goal of the project. And trust me, it does not really 
encourage to spend this time.

Also, don't worry I read comments even if I don't always reply, so all very 
valuable feedback raised -thanks @yok and @krolaw that gives very valuable 
reproduction scenario and logs- is taken into account. I don't always reply 
because of lack of time but I always investigate logs.

Original comment by r3gis...@gmail.com on 7 Feb 2012 at 8:39

• Changed state: Accepted

[GoogleCodeExporter]

I'm happy to report (while I keep fingers crossed) that the last two days 
(since I've updated to r1252) I'm running CSS without the problem. :)

I don't know how important was the change in r1252 (fix for issue 1564, 
considering Ethernet as WiFi), but the result so far is positive. CSS gets 
registered as soon as phone gets connected to WiFi... Before that CSS may stuck 
on event of connecting to a new WiFi and sit there until I kill the process. 
And so far it survived several re-connections without that big problem :)

Now we may start talking about other issues with CSS ... ;) 

Original comment by yok...@gmail.com on 11 Feb 2012 at 4:15

[GoogleCodeExporter]

The changes that probably impact this issue is r1249 and it becomes usable with 
r1258.

In fact, I previously used the method of the stock android sip application to 
stay registered. They used some hysteresis method to wait 2 sec in order to be 
sure the wifi network is up. However they've changed that in android 4.0. As 
consequence in r1249, I commited what I had under testing integrating their new 
method -- which is basically what we had in csipsimple before integration the 
stock sip app way minus the change to flag the ongoing notification as a 
background running app to avoid kills from android.

So glad to hear that it helps. My fear is that it's not backward compatible 
with older android versions. That's why I have to do some basic regression test 
before to tell it's fixed. But if some have time here to do some tests with 
latest binary it will be welcome.

Also, another point is that this method may consume more data than previous one 
that did the job only if IP changed (but was also potentially one root cause of 
the problem, and more with android 4.0 that does not announce IP the same way). 
The r1258 should be there to at least reduce the double start when starting the 
service first, but I think that anyway the app will try to restart sip more 
often all the more so as 3G network is allowed.
So I'm also interested in changes in data consumption and battery consumption 
you get with latest version.

Original comment by r3gis...@gmail.com on 11 Feb 2012 at 11:06

[GoogleCodeExporter]

Yay it works :-)

Original comment by kro...@gmail.com on 13 Feb 2012 at 7:32

[GoogleCodeExporter]

Found this issue after noticing the same issue on my HTC Thunderbolt with 
CSIPSimple and a derivative of CM7 (Liquid Smooth 3.2 based on Gingerbread 
2.3.7).

Moved to the nightlies after reading this issue thread and installed r1277 and 
so far so good :)

Thanks for your work. Now if Just gotta get it worked out on my Triumph.

Original comment by thecooln...@gmail.com on 26 Feb 2012 at 5:28

[GoogleCodeExporter]

Sorry, spoke too soon. I got a notification on my phone and went to pick it up 
and check it and sure enough, there was no CSIPSimple in the status bar. 
Instead, my pbxes account was sitting as Inactive instead of "Unauthorized".

Original comment by thecooln...@gmail.com on 26 Feb 2012 at 5:44

[GoogleCodeExporter]

Beginning with 1279 and now 1281 I have the returned problem beck. :(
CSS refused to register. Trying to set account off / on shows:
"Error while registering - Service Unavailable"
Turning off/on WiFi doesn't help. Calling "Disconnect" menu - doesn't help 
either. The only solution is to kill CSS processes. It has already happened 
several times, including 2 times today...

Original comment by yok...@gmail.com on 29 Feb 2012 at 3:09

[GoogleCodeExporter]

Repeatable test case.  Move to edge of wifi range, so connectivity is poor, yet 
phone does not switch to wifi.  Wait until sip registration times out.  (I 
think accounts will change status to inactive.)  Now move closer to the access 
point so packets may flow reliably.  Csip should eventually retry and register, 
but it seems locked on in active and cannot make it reregister without force 
closing.   Leaving wifi for

Original comment by kro...@gmail.com on 2 Mar 2012 at 7:52

[GoogleCodeExporter]

3g and back again works fine :-)  suspect similar behaviour in poor reception 
3g/2g areas.

Original comment by kro...@gmail.com on 2 Mar 2012 at 7:54

[GoogleCodeExporter]

Is this working as of now? 

Original comment by nblanch...@movitas.com on 5 Mar 2012 at 1:56

[GoogleCodeExporter]

Issue 1272 has been merged into this issue.

Original comment by r3gis...@gmail.com on 5 Mar 2012 at 4:15

[GoogleCodeExporter]

I'm happy to announce my situation.

== environment ==
GingerBread 2.3.4
Kernel 2.6.35.7
CSipSimple r1326

1. when 3G on & Wifi off,
run CSipSimple(CSS) and it works.

2. when Wifi on, (automatically 3G is off)
CSS connection is closed and opened (good).

3. when Wifi off, (automatically 3G is on) 
CSS connection is closed and NOT opened (bad).

4-1. when manually 3G off and 3G on,
CSS connection is opened (good)

or 

4-2. when run CSS icon again
CSS connection is opened (good)

This case is repeatable...

I hope this can give any clue to this problem..

Thanks.

Original comment by hansg...@gmail.com on 14 Mar 2012 at 6:57

[GoogleCodeExporter]

one more thing... 

5. after some time, when 3G goes off and on (unstable 3G)
CSS connection is closed and NOT opened(bad)

From these situations, I think, 
some events(3 & 5) are missing ... 
so re-registration code cannot be called.
the common part between 3 & 5 is that 3G becomes on automatically...
as the 4-1 shows, manual 3G off & on works fine.

one more test case,
6. when 3G off and Wifi on, 
I turned off and on the Wifi AP, so wifi signal goes off and on.
CSS connection is closed and opened (good)

again, I hope this can help...
Thanks. 

Original comment by hansg...@gmail.com on 14 Mar 2012 at 7:44