Multiple accounts and NAT/STUN/public IP

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create two accounts: the first has server in same subnet of wifi link, the 
second is on internet, reached via router that apply NAT on internal addresses
2. beginning with both account disabled, enable first the internet one, then 
the local one
3. activating only the local one then there's no problem (after restarting 
csipsimple)

What is the expected output? What do you see instead?
The local one will not register, tracing sip packets in each field it report 
the external router address instead of local one and then local server cannot 
reach it

What version of the product are you using? On what operating system?
HTC Wildfire 2.1 Eclair

Please provide any additional information below.

Those are two fields taken from REGISTER packet:

Via: SIP/2.0/UDP 
89.120.100.63:5060;rport;branch=z9hG4bKPjbQcWcHljyI18MvElx8y6uC6xAv.XvMpG
Contact: <sip:65@89.120.100.63:5060>

The 89.120.100.63 should be 10.0.1.9.

Original issue reported on code.google.com by karnevil...@gmail.com on 5 Nov 2010 at 4:55

[GoogleCodeExporter]

Sorry, forget adding csipsimple revision: 0.00-15-09

Original comment by karnevil...@gmail.com on 5 Nov 2010 at 5:52

[GoogleCodeExporter]

Yes unfortunately that's a back side of pjsip behavior. 
As it try to get rid of NATed network detecting your public IP (as if you 
activate stun), it try to always use it's public IP for all account.

The sip stack consider you have an unique public IP and as consequence as soon 
as it detect a public IP for one account it consider this IP is valid for all 
account. It has advantages (speed of registration in standard cases) but also 
disavantages (your use case is typically one big disavantange of this 
approach). 
But that's the behavior of the stack CSipSimple is relying on.

I'll check if there is not an extra option in pjsip that could help to solve 
this kind of issue (if so, I'll add an option in settings).
Anyway, if you have the complete hand on your network, what I can advise to you 
is :

* Assign a static dhcp lease to your mobile device inside the enterprise
* Use expert wizard for your enterprise account (you can switch from existing 
wizard using menu > choose wizard)
* Use "Force contact" field and fill it with display name 
<sip:username@10.0.1.xxx> 
where 10.0.1.xxx is the static dhcp lease.
I don't know if it will help for via field but at least for contact it will 
solve your problem.
That's a temporary hack.

If your need is to be registered only with your enterprise ip-pbx on your local 
network and with the public on the public network, another more user friendly 
solution would be something that activate/deactivate account according to the 
current android setting/configuration state. 
It has been discussed in another issue here (about intent to 
activate/deactivate accounts and Locale application)

So open point for me : I'll check if there is any way to bypass this behavior 
in pjsip.

Else will probably linked to the issue about activation/deactivation of account 
according device state (if the use case is OK for you, and if you don't 
actually need both account to be registered while in your local network... but 
I guess that in this case your local sip server can be a good sip proxy for 
your requests to another sip server).

Original comment by r3gis...@gmail.com on 6 Nov 2010 at 8:50

• Changed state: Accepted

[GoogleCodeExporter]

Ok, this is not big problem for us now, it's only an add-on as my main target 
is using it in our enterprise ip-pbx (and I don't exclude that in future I 
could publish it on internet in order that our terminals could get connected to 
it also around the world).

Original comment by karnevil...@gmail.com on 8 Nov 2010 at 1:19

[GoogleCodeExporter]

Issue 536 has been merged into this issue.

Original comment by r3gis...@gmail.com on 24 Dec 2010 at 5:38

[GoogleCodeExporter]

Seems to be taken into account for pjsip-2.0. 

So CSipSimple will automatically benefit it as soon as I'll move to pjsip-2.0 : 
For reference ticket : http://trac.pjsip.org/repos/ticket/539 

It will also improve battery life according to the ticket :)

Original comment by r3gis...@gmail.com on 8 Jan 2011 at 1:28

[GoogleCodeExporter]

That's good, but, about battery life, the main problem is the partial wake-lock.

After weeks of testing, definitively it's the big difference in standby battery 
life.

Without partial wake-lock, standby time is not so less by having CSipSimple 
active or not, for usual activity of the phone I don't see difference. But in 
this case the problem is that Register timeout is not honoured, so looking at 
asterisk log, phone will re-register with random time, most of the time when 
timeout is expired (thus it doesn't answer to incoming call).

With partial wake-lock I have to recharge each day, also with few minutes of 
calls. But in this case register timeout is honoured, thus always answer 
incoming call.

No other functionality are affected by this settings (in all my testing).

Original comment by karnevil...@gmail.com on 10 Jan 2011 at 5:23

[GoogleCodeExporter]

Issue 481 has been merged into this issue.

Original comment by r3gis...@gmail.com on 5 Mar 2011 at 1:17

[GoogleCodeExporter]

Issue 774 has been merged into this issue.

Original comment by r3gis...@gmail.com on 7 Mar 2011 at 10:47

[GoogleCodeExporter]

Issue 820 has been merged into this issue.

Original comment by r3gis...@gmail.com on 22 Mar 2011 at 12:20

[GoogleCodeExporter]

Issue 1134 has been merged into this issue.

Original comment by r3gis...@gmail.com on 9 Jul 2011 at 7:59

[GoogleCodeExporter]

Issue 1251 has been merged into this issue.

Original comment by r3gis...@gmail.com on 2 Sep 2011 at 10:12

[GoogleCodeExporter]

If this bug tracking system allows to edit the subject of an issue, this one 
should be change to contain STUN in its subject. There are duplicates filed 
monthly, and I for sure know that #1251 wouldn't have been filed if I found 
this issue while searching for STUN ;)

Original comment by zugsch...@gmail.com on 2 Sep 2011 at 11:05

[GoogleCodeExporter]

Done :)

But no problem with the duplicate don't worry ;) 

I'm also often lost with all open issues. I should take time to treat all 
issues and merge duplicates/obsolete. (But for now I've not enough times to do 
so, when I got little time for csipsimple, I prefer to actually produce code ;) 
). 

Original comment by r3gis...@gmail.com on 2 Sep 2011 at 12:32

• Changed title: Multiple accounts and NAT/STUN/public IP

[GoogleCodeExporter]

Issue 1351 has been merged into this issue.

Original comment by r3gis...@gmail.com on 29 Oct 2011 at 6:50

[GoogleCodeExporter]

For reference, a new more precise ticket has been created on pjsip project 
about this particular point for pjsip-2.0 : 
https://trac.pjsip.org/repos/ticket/1412

BTW, I've already a working patch for this special use case, but I will wait 
for pjsip implementation in their official 2.0 release.
A release of csipsimple will be done soon based on pjsip 1.x with current trunk 
(which is freezed and waits for stability feedback). Once this release will be 
done, the nightly builds will be based on pjsip-2.0 and it will be possible to 
have either what was added by pjsip guys or my patch.

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

• Changed state: Started

[GoogleCodeExporter]

Issue 1447 has been merged into this issue.

Original comment by r3gis...@gmail.com on 23 Dec 2011 at 1:30

[GoogleCodeExporter]

Issue 1464 has been merged into this issue.

Original comment by r3gis...@gmail.com on 1 Jan 2012 at 9:31

[GoogleCodeExporter]

Hello,
Same behaviour here with a Freebox SIP account (public IP) and a Aastra Nexspan 
(private network).

In my case it seems that if the private IP account registers first, it works.

Original comment by laurent....@gmail.com on 8 Jan 2012 at 4:21

[GoogleCodeExporter]

Yes indeed. The sip stack as only one "global" ip address. So if the first 
account to register is the private one it will work for first registration. 
However, re-registration will be broken then.
I really hope pjsip guys will take the point into account.

Original comment by r3gis...@gmail.com on 8 Jan 2012 at 4:34

[GoogleCodeExporter]

For those experiencing the problem, I have had success buy turning on NAT 
support for the account on the *server* on the private network (or all servers).

This sounds backwards as there is no NAT going on for that link, but it makes 
the server ignore the Via header and use the packet's origin so allows multiple 
accounts to work until the issue is fixed!

Original comment by SpiderErrol on 14 Mar 2012 at 1:00

[GoogleCodeExporter]

The https://trac.pjsip.org/repos/ticket/1412 issue is now 5 months old. I can't 
see any process in https://trac.pjsip.org/repos/log/pjproject :(

Is there a chance that it'll be solved soon?

Original comment by szims...@gmail.com on 19 Mar 2012 at 11:21

[GoogleCodeExporter]

You should ask on pjsip dev mailing list ;). 

I personally have no news about this enhancement request we did. 
If I get some time to propose a patch to pjsip guys I'll do, but I'm more 
focused on stuff on CSipSimple/android side for now. 
So we wait for pjsip developers to implement that, and then csipsimple (and all 
other apps based on pjsip) will automatically have the feature. (I'll have some 
low effort to do to reflect the setting in the expert wizard, but can be done 
quickly once the feature is in the sip stack). 

Original comment by r3gis...@gmail.com on 19 Mar 2012 at 11:57

[GoogleCodeExporter]

I sent a mail to them ;)

Original comment by szims...@gmail.com on 19 Mar 2012 at 12:33

[GoogleCodeExporter]

Good news, it's now in pjsip. (cf https://trac.pjsip.org/repos/changeset/4218)
I just started the work to integrate that in csipsimple user interface. Will 
land soon :)

Original comment by r3gis...@gmail.com on 7 Aug 2012 at 1:06

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

This issue was closed by revision r1763.

Original comment by r3gis...@gmail.com on 7 Aug 2012 at 6:13

• Changed state: Fixed