Call Hang-up on pbxes.org and TCP

[GoogleCodeExporter]

I know this is a known issue but the problem is that the internet provider in 
my office somehow blocked UDP traffic for VoIP. So my sip phone rings only on 
TCP connection but the not hang-up problem is a big issue. Is there anyway that 
could be fixed for TCP. In sipdroid this issue is not present but I prefer 
csipsimple for a number of reasons.

Original issue reported on code.google.com by amishev....@gmail.com on 21 Jan 2011 at 9:31

[GoogleCodeExporter]

Sipdroid is mainly developped by pbxes.org guys... so they don't really bother 
with RFC and SIP standards... they just do sipdroid works for their server.

There is some possible workaround that could make change the RFC compliant 
behavior of pjsip (the sip stack csipsimple is relying on). But it requires 
development on my side. As the "bug" is not on my side it would be better to 
fix pbxes.org server behavior (all the more so as if they fix that they will 
not be compliant only with csipsimple but with all SIP client that follow 
strictly the SIP standard).

If they don't fix and if I have time to dive in pjsip code to find a clean 
workaround that will not break things with other SIP server that follow SIP 
standard, I'll do but that's not a priority for me.

Original comment by r3gis...@gmail.com on 21 Jan 2011 at 10:01

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Issue 613 has been merged into this issue.

Original comment by r3gis...@gmail.com on 22 Jan 2011 at 1:21

[GoogleCodeExporter]

Yesterday I installed the latest trunk version of csipsimple. I added the 
pbxes.org account and changed the wizard to "Expert". I set the transport to 
TCP. Everything was working fine. I checked the transport a few times to make 
sure it is set on TCP. It hang-up perfectly. I actually taught that you have 
fix it :). But this morning I restarted my phone and the hang-up stopped 
working again.
I just decided to share this information to you as I taught is odd.

Original comment by amis...@gmail.com on 22 Jan 2011 at 4:03

[GoogleCodeExporter]

Was probably due to the fact there were a remaining UDP registration active on 
pbxes.org server. That's weird cause in this case we think to succeed but... 
actually not ;).

I will announce if I do a fix on that point on this issue. It will require me 
to hack the standard behavior of pjsip so will be done independantly of other 
fixes to be able to isolate/revert my changes easily and as consequence I'll 
probably not forget to announce and ask you to test ;) . 

Original comment by r3gis...@gmail.com on 23 Jan 2011 at 10:59

[GoogleCodeExporter]

Not fixed on the latest build... usually 20s till hangup on pbxes tcp

Original comment by ysreis...@gmail.com on 28 Jan 2011 at 8:43

[GoogleCodeExporter]

Just installed new 612 market release and still have the delayed hang up.  
Also, PBXes hold music works on UDP, but not on TCP.

Original comment by sc...@ryskamp.com on 31 Jan 2011 at 7:59

[GoogleCodeExporter]

Again and again... that's cause pbxes.org DOES NOT SUPPORT true SIP (according 
RFC) over TCP !!!! SO DO NOT USE PBXES.ORG WITH TCP !!! DO NOT !

I'll notify on this thread if I found a workaround that change the RFC (rfc are 
standards) SIP behavior to work with the weird way pbxes.org manage TCP !!! But 
meanwhile DON'T use TCP with pbxes.org. You can also cry to pbxes.org cause 
their server is not compliant with rfc regarding TCP...

Original comment by r3gis...@gmail.com on 31 Jan 2011 at 8:41

[GoogleCodeExporter]

Hi r3gis.3R. I understand your frustration - the problem lies with pbxes.org's 
non-compliant behavior, not with csipsimple.

However, for a number of people (such as myself) TCP is virtually a requirement 
as our wireless provider deletes UDP NAT table entries very quickly (I'm with 
Telus, and I think I required a UDP keep-alive interval of 15 seconds). This 
has a major negative effect on battery consumption (and also bandwidth use to 
some extent), so TCP is the only practical option. And, for better or for 
worse, pbxes.org is the only free solution for SIP TCP (voxalot charges a fee, 
although small). 

So, when you say don't use TCP with pbxes.org, what you're in effect saying to 
at least some people (those who can't use UDP for reasons above, and either 
can't or won't pay for a voxalot account) is that they cannot use csipsimple.

Note that I'm NOT criticizing your position - pbxes.org is the problem here, 
not csipsimple. But, just pointing out that if TCP and pbxes.org is not 
possible with csipsimple, then the only alternative for at least some people is 
to not use csipsimple.

On a side note, can you tell me if you folks have done any testing with 
csipsimple and TCP with FreeSWITCH? I gave it a try using FS on a home machine 
and ran into problems (as a comparison, sipdroid was fine). So, I'm wondering 
if you can tell whether it should work. Thanks.

Original comment by jbr...@gmail.com on 31 Jan 2011 at 6:38

[GoogleCodeExporter]

Yes I did tests with freeswitch and get good results. Also opensip used by ippi 
works fine with TCP.

Indeed, for those who wants to use pbxes.org I'd advise you to use sipdroid 
which is developed by pbxes.org guys. 
It's also an opensource app so that's fine ;). 
You can also try the excellent linphone which behaves differently with TCP and 
as consequence should probably pass the problem with pbxes.org.

I develop just for my pleasure. I have absolutely no commercial goal. If 
developping csipsimple become a constraint for me I'll stop. However keep in 
mind... that's opensource !!!! !!! :) If anybody wants to make a workaround for 
pbxes.org (that will not break pjsip compliance with the rest of the world ;) 
)... he will be welcome !! 

I do not tell anybody "use my app it's the best". First cause I hope that's not 
"my" app but the app of "users", and then cause I truly believe in opensource 
and with the fact choice is really important. CSipSimple is just one of 
possible choice.
I really have the same approach than firefox has with the web. They make an 
open app to improve the open web !

Original comment by r3gis...@gmail.com on 31 Jan 2011 at 7:42

[GoogleCodeExporter]

I was also struggling with this a while ago 
(http://code.google.com/p/csipsimple/issues/detail?id=50#c11). I even went so 
far as to 
 try a hack within the sip stack to always send the BYE over all transports. I also experimented with complex setups using sipsorcery and/or voxalot with forwarding etc to some success. My provider now supports native TCP so I no longer need these workarounds.

The best solution whould be if somebody with a paid pbxes.org account asked on 
the support forum for a solution implemented in pbxes since this is also a 
problem for other sip clients.

Original comment by michael....@gmail.com on 2 Feb 2011 at 4:38

[GoogleCodeExporter]

I assume we already agreed about that this is not a csipsimple issue but I 
would like to share something.
Recently after all pain with tcp of pbxes.org I registered account with 
sipgate.co.uk. I use the latest market version and the default setting for 
sipgate. Because of my network (problems with NAT and UDP, works fine with 
TCP). It happens the following. I ring the test number 10000. I can hear the 
machine talking. I press the hang-up button. The voice immediately disappears 
but csipsimple says it is still connected. After a few seconds it hangs-up. In 
my opinion this is due to one-way connection. The csipsimple send hang-up code 
and the server hangs-up but it does not receive any confirmation of that so it 
does not show the line is closed.
When somebody calls me on sipgate. I can answer but unfortunately it is one way 
audio again. This time I do not hear nothing but the other side can hear me.
I do not know if I'm right but I can say it is working fine at home where I do 
not have any problems with the connection both on TCP and UDP.
I also do not know if there is any connection between this particular NAT issue 
and the problem with pbxes.org. Just decided to share the information.
Cheers.

Original comment by amis...@gmail.com on 2 Feb 2011 at 5:01

[GoogleCodeExporter]

As for the fix I think that what is suggested by benny on the pjsip mailing 
list is a good solution :
http://comments.gmane.org/gmane.comp.voip.pjsip/13049

Would not hurt pjsip standard behavior and may provide a way to enable/disable 
the workaround at application level. If I get some time to try it I'll do.

Original comment by r3gis...@gmail.com on 2 Feb 2011 at 5:45

[GoogleCodeExporter]

@michael, off-topic, but can you tell me who your provider is that supports 
TCP? The only one I know that does is Flowroute, and unfortunately they don't 
offer Canadian DIDs. My current provider, voip.ms, only supports UDP. 

Thanks in advance.

Original comment by jbr...@gmail.com on 2 Feb 2011 at 6:01

[GoogleCodeExporter]

Regis:

I have an enormous amount of admiration for you and your efforts with 
csipsimple.  I've tried all of the other Android SIP clients and this one is by 
far the best.  Best audio quality, best interface, most options.  Sipdroid 
doesn't have G729 codec, either.  G729 works with my PBXes outgoing, but not 
incoming using Google Voice trunk, btw.  Not sure why not both.

Keep up the great work.  You are much appreciated.

Original comment by sc...@ryskamp.com on 2 Feb 2011 at 10:39

[GoogleCodeExporter]

@r3gis, I used to have the problem of no hang-ups and also failing to stay 
registered to pbxes.org.

Captivate(Eclair)+csipsimple++pbxes+callcentric

Now that I've added ;transport=tcp to my SIP URI and my Proxy URI, both 
problems are fixed. I've set a keepalive timeout at 3600 seconds and I stay 
registered! Hangups happen immediately. No changes were made on the trunk side. 
Got my answer from these forums, thanks a lot. My stand-alone wifi-only 
softphone works great with csipsimple-

Original comment by JimMof...@gmail.com on 3 Feb 2011 at 5:31

[GoogleCodeExporter]

@Jim : I think that as soon as the old UDP registration will expire your tcp 
configuration (which is absolutely correct to do tcp, that's what tcp option 
implicitly do), will fall in the hang-up problem again.
That's cause when there is an udp registration active, pbxes.org accept the 
response that it actually ask to be done over udp. When only one tcp 
registration is active on their server, in one response they ask the sip client 
to use a route that does not use TCP (so by default it should be UDP), but 
ignore requests done over udp.

Unless they fixed things meanwhile??? would be great... 
Just to give some hope else to listeners of this thread, I've started yesterday 
a module to force tcp even if sip server actually ask udp. No target date for 
that, I do it only when I've some really free time to spend or want to code in 
C instead of java ;).

Original comment by r3gis...@gmail.com on 3 Feb 2011 at 5:44

[GoogleCodeExporter]

So far over two days, moving between several different wireless connections, I 
have not had the hangup problem return. A UDP registration only lasts a few 
(<100) seconds right? I have the mobile timeout set to 999999999 (no sim card 
in the phone) and the wifi timeout set to 3600. So in theory within two hours 
(at most) my registration session with pbxes should be killed, right? 

But I've had an active registration maintained for many hours; while the phone 
is sleeping I get inbound calls functioning perfectly after 2, 3, 4 hours 
asleep... 

I have a free account right now on pbxes.org, maybe they fixed this issue? I'll 
do some more testing, but right now my registration seems stable over several 
hours and the hang-up issue hasn't returned...

Original comment by JimMof...@gmail.com on 4 Feb 2011 at 2:03

[GoogleCodeExporter]

@Jim:
Would you share you entire configuration for pbxes.org (without your username 
and password ofcourse :) ). So I can try this fix.

Original comment by amishev....@gmail.com on 4 Feb 2011 at 9:49

[GoogleCodeExporter]

Issue 705 has been merged into this issue.

Original comment by r3gis...@gmail.com on 10 Feb 2011 at 8:05

[GoogleCodeExporter]

Yeah, I tried adding ;transport=tcp to my pbxes settings. Didn't notice a 
difference with the hangup delay. I also have the Transport option set to TCP.

Original comment by kni...@gmail.com on 15 Feb 2011 at 4:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

After further testing on this issue, it seems that I can hang up immediately 
when on Verizon's 3G network. When on my home WiFi connection, there is a hang 
up delay.

Original comment by kni...@gmail.com on 15 Feb 2011 at 10:38