Configuring non-standard port on Asterisk (50600 in my case) causes calls made TO CSipSimple to terminate in about 1 minute.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Installed Asterisk 1.8.4.4
2. Added a user 1234 and 1235 in sip.conf
3. Changed standard bind port from 5060 to 50600 (bindport).
3. Registered CSipSimple with 1234, and a SPA2102 box with 1235 using the local 
IP address:port (192.168.2.1:50600). I used the simple wizard to configure 
CSipSimple. The setup was tested on a local network.
4. Called extension 1234 using the SPA2102 (i.e. from user 1235).
5. CSipSimple rings, I pick up the call, there is audio and everything seems to 
operate. However after about 60 seconds, the call terminates.

6. The call does NOT terminate when I call the other way (from CSipSimple to 
the SPA2102).

7. The call does NOT terminate when I use Linphone instead of CSipSimple.

8. The call does NOT terminate when I use the standard SIP port 5060 even when 
I use CSipSimple. This points to a possible problem with how CSipSimple handles 
non-standard SIP ports???

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

- I expect the call not to terminate.

What version of the product are you using? On what operating system?

- The Android app. The latest version from the Android Market.

Please provide any additional information below.

- I hope you are able to reproduce this. I am fairly certain from my testing 
that changing the bindport to 50600 was sufficient to reproduce the behavior.

Original issue reported on code.google.com by iiordanov@gmail.com on 12 Sep 2011 at 3:23

[GoogleCodeExporter]

I just tried, and setting bindport to 5061 does not reproduce the problem! I 
hope this is helpful information.

Original comment by iiordanov@gmail.com on 12 Sep 2011 at 3:29

[GoogleCodeExporter]

My apologies for the rapid rate of comments, but I am doing active testing to 
help speed this up. I tested setting port 9999 (4 digits), which worked 
perfectly, and then setting port 10001 (5 digits), which reproduces the 
problem. I think that this could be really helpful information! :)

Original comment by iiordanov@gmail.com on 12 Sep 2011 at 3:41

[GoogleCodeExporter]

Indeed, that's interesting point.

Normally max TCP port for userspace is 65534 for most unix installation. 
However, it's hightly possible that your android OS does not allow to go up to 
this port for user space. 
So maybe not linked to the app but more to the android OS and rights it grants 
to an app. Since everything is managed on pjsip side it should be fine with non 
standard ports (pjsip is a well known and widely used sip stack and this kind 
of use case is highly tested on the sip stack side).

However, I'd be interested if you can collect logs (see the wiki page about 
HowToCollectLogs). It could confirm my guess.
Thx.

Original comment by r3gis...@gmail.com on 12 Sep 2011 at 8:11

[GoogleCodeExporter]

Hi R3gis,

Sorry for the delay! Here is what I'm thinking.

1) To your point about the Android OS being the problem - please note that 
Linphone has no trouble maintaining a call even when the SIP port is set to 
something higher than 10,000.

2) PJSip may still be to blame, because Linphone has a different SIP stack 
(right??), and it is operating fine under the same conditions.

Do you still want me to collect logs? I still think the problem is not with 
Android, and is either with pjsip or with Csipsimple. If you have nothing to do 
with port numbers in CSipsimple, then the problem certainly lies with pjsip, 
and you can upstream this bugreport to them :D.

Cheers and thanks for looking into this for me!
Iordan

Original comment by iiordanov@gmail.com on 19 Sep 2011 at 3:13

[GoogleCodeExporter]

Hi Iordan, I did a couple of test just to be sure.
I've no problem at all with a binding port set to 50600.

Are you sure we are talking about the same thing when saying binding port? 
In CSipSimple, binding port, is the local port on which the softphone listen on 
it side. Usually it is useless to change. Most of the time what is to be 
changed is the port of the registrar/proxy. But obviously this setting is not 
in the global configuration but in the account configuration (set 
registrar/proxy to server_ip:50600).

If you are absolutely sure you want to change the local binding port of the 
client, and that this does not work, yeah, indeed, I'm still interested by logs 
since I do not reproduce this with all my phones ;).

Thanks!

Original comment by r3gis...@gmail.com on 25 Sep 2011 at 8:54

• Changed state: Need-Details

[GoogleCodeExporter]

Hi,

I am not talking about changing the local binding port! I am talking about 
using a non-standard REGISTRAR port above 10000 (50600 in this case).

I hope this clears things up! Thanks for taking a look :).

Original comment by iiordanov@gmail.com on 26 Sep 2011 at 2:50

[GoogleCodeExporter]

Ok so about the registrar port the right place is not in global settings.

Just keep it to 0 (the default is to choose a random free port).
Then in your account, edit the server field.
Instead of server_ip (or server_domain), type server_ip:50600 (or 
server_domain:50600).

Once this is done, you have to make sure your sip server is properly configured 
to reply correctly the invite. Most sip client does not respect fully the RFCs 
and continue to reply the initiated ip:port instead of following what is 
replied by your server.
On it side, pjsip is very respectful with SIP RFCs. Sometimes it leads to some 
weird behavior which is not due to the client but to the way the server reply. 
(For example the symptom you describe are often encountered with TCP support 
which is not properly managed by the server).

If you can collect logs (see HowToCollectLogs wiki page), I'll be able to 
explain you what's going wrong with the way your server reply. AFAIK, Asterisk, 
if correctly configured, should not be buggy regarding this point. But that's a 
matter of configuration of the server.

Original comment by r3gis...@gmail.com on 26 Sep 2011 at 6:29

• Changed state: WrongConfig

[GoogleCodeExporter]

Hi,

I've been configuring only the registrar port all this time, not the bind
port for csipsimple. I am not sure where the confusion arose. :) If I was
not configuring the registrar port properly, my client would not have
registered at all! The problem here is call termination after 1 minute, not
inability to call.

I will collect logs when I get a chance. Also, I believe my asterisk server
is not buggy and is configured properly. Otherwise linphone (which works
with these settings without terminating the call) would not have worked
either.

Have you personally tried csipsimple on android registering to a sip server
on a port greater than 10000?

Cheers, and thanks for looking into this!
Iordan

Original comment by iiordanov@gmail.com on 26 Sep 2011 at 1:50

[GoogleCodeExporter]

Ok.

About the registrar, yes it was part of my tests, but I didn't try to monitor 
call establishement. I'll do that to be sure there is not something buggy in 
pjsip.

My point was about what happen after call is established. Many sip stacks does 
not update dialog with what is sent from server. It's usually harmless. But it 
does not respect SIP RFC.

For example there is an open issue with TCP and pbxes.org. The call establish 
properly, but the server update the dialog using transport UDP. Sipdroid (which 
is developped by pbxes.org guys), does not update the dialog and keep using the 
TCP transport to hack and end the call. pjsip on its side update the dialog and 
as the server is now telling to use UDP, just use udp. As consequence, any hack 
and bye packets sent to pbxes.org server are just ignored.
In this case, the problem is not on pjsip side since it follow SIP RFC but on 
what is replied by pbxes.org. (It should either reply with TCP transport or 
support the fact the client reply on UDP).

So it's not to exclude that at some time your server behaves the same way and 
tell pjsip to update the dialog with another port (for example if 5060 it is 
also opened on your server). 
So pjsip will try to continue using 5060 (and in this case, asterisk does not 
allow a sip client to start talking on another port).
This is very tricky but according to what you describe, it could be an 
explaination to what happens. 
And the most tricky thing is that there is really few sip stacks that behaves 
correctly regarding this part of the specification... so one could think the 
server is properly configured cause it works with most sip clients, while it 
actually take advantage of a miss in those sip clients.

So, logs get from csipsimple (no need to wireshark, logs created by csipsimple 
should be enought), could help to tell whether this is the root of the problem.

On my side I'll try to monitor a call with a registrar/proxy port higher than 
10000 to see if there is something weird on pjsip side :)

Original comment by r3gis...@gmail.com on 26 Sep 2011 at 2:53

• Changed state: Need-Details

[GoogleCodeExporter]

Hi Regis,

Alright! Thanks for all the input so far. Please do let me know if you get any 
results, and I'll follow up with logs when I get a bit of time to collect them!

Cheers,
Iordan

Original comment by iiordanov@gmail.com on 26 Sep 2011 at 11:57