OpenVPN support

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Have an asterisk server in a VPN
2.Connect with phone to that VPN
3.Tell csipsimple to connect to the server in the VPN

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

What version of the product are you using? On what operating system?
0.00-15 on Cyanogenmod 6.0 (Froyo)

Please provide any additional information below.
routing problem?

Original issue reported on code.google.com by yuah.p...@gmail.com on 18 Nov 2010 at 4:41

[GoogleCodeExporter]

Yes you're right I nothing is done for VPN for now. I'll do that soon but have 
to root one of my phones to be able to see how things goes with OpenVPN.

Original comment by r3gis...@gmail.com on 18 Nov 2010 at 9:41

• Changed title: _OpenVPN support _
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

on both my adp1 and my n1 using openvpn on Cyanogenmod 6.0 I had no problem 
registering csipsimple to asterisk set to listen on the internal openvpn 
ip/bridge.    Often quality was choppy but I was able to register.   

Do you have something like a openvpn connecting on tcp and asterisk listening 
on udp?

Original comment by wheresau...@lavabit.com on 18 Nov 2010 at 10:06

[GoogleCodeExporter]

also, I should add chopyness was probably due to my lack of openvpn/asterisk 
tuning skill.  Its been crystal clear since Ive dropped openvpn and utilized 
encryption in the tls/srtp build.

Original comment by wheresau...@lavabit.com on 18 Nov 2010 at 10:08

[GoogleCodeExporter]

I have asterisk listening on OpenVPN internal ip. Both, asterisk and OpenVPN 
are listening on UDP sockets and I keep having timeout on registering. With 
SipDroid I have no troubles registering (but it does not support 2G).

Thanks for the reply.

Original comment by yuah.p...@gmail.com on 19 Nov 2010 at 8:36

[GoogleCodeExporter]

Well, anyway, if I can help with some test, just ask me to do it. Right now I 
think that csipsimple is not sending packages through the VPN. Any clues ?

Original comment by yuah.p...@gmail.com on 21 Nov 2010 at 12:55

[GoogleCodeExporter]

Issue 588 has been merged into this issue.

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It seems that csipsimple suffers from the same bug(/feature) as SipDroid. See: 
http://code.google.com/p/sipdroid/issues/detail?id=368#c10). 

I can confirm by looking at the debug log from asterisk that csipsimple sends 
the ip-address from the wrong interface when using VPN.

----------------------------------------------

<--- SIP read from UDP:172.16.0.6:5060 --->
REGISTER sip:172.16.0.1 SIP/2.0
Via: SIP/2.0/UDP 
MY_3G_IP_ADDRESS:5060;rport;branch=z9hG4bKPjqudlk.qa7d22EpWk3Kx.7A6C.3GkFuBm
Max-Forwards: 70
From: "MY ID" <sip:MY_USERNAME@172.16.0.1>;tag=lZK4v7vKXhr0v6hUFv7tuKhxlybJ9vtj
To: "MY CALLER ID" <sip:MY_USERNAME@172.16.0.1>
Call-ID: oqMbT7BmUuT6OkcOARr0zegF7OQrvnIC
CSeq: 41338 REGISTER
User-Agent: CSipSimple
Contact: "MY ID" <sip:MY_USERNAME@MY_3G_IP_ADDRESS:5060;ob>
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS
Content-Length:  0

<------------->
--- (12 headers 0 lines) ---
Sending to MY_3G_IP_ADDRESS : 5060 (no NAT)

----------------------------------------------

btw. The patch for sipdroid looks relatively simple. Isn't this an option to 
include here as well? A more elegant way could be that upon connecting, we 
resolve the "Server" adress, check the routing table for the corresponding 
device and extract the ip address....

Any thoughts on this? I hope this can be fixed, I find CSipSimple far superior 
compared to SipDroid.....

Original comment by j.stam...@gmail.com on 30 Jan 2011 at 4:58

[GoogleCodeExporter]

Well.. what about a combobox on preferences where you can choose the
interface to use among the available network interfaces????

That would be easy and more versatile...

Original comment by yuah.p...@gmail.com on 30 Jan 2011 at 5:13

[GoogleCodeExporter]

Not sure that's the same problem. 
CSipSimple relies on pjsip which acts in the C stack. So applying the same 
patch is not possible as it. It has to be solved a clean way in the C stack. 

However, to say the truth I didn't had a look to this issue yet. If anybody 
would like to contribute to the project on this point he will be welcome ;). 
But if I've time I'll do more tests and try to support VPN.

Original comment by r3gis...@gmail.com on 30 Jan 2011 at 5:15

[GoogleCodeExporter]

@yuah : I don't think that's the problem. I think that all I need is to listen 
when VPN comes up and when up ask to pjsip to re-register.

Cause VPN is under the application layer. Pjsip acts on the native stack and 
does not bother with interface. It resolve the external IP using a much more 
clean way than what is done by sipdroid. 
(And for info, I started csipsimple cause sipdroid guys ignored my questions on 
the way they detect the public ip and as I had no reply... I started to search 
for another sip stack and found pjsip which is much more reliable ;) ... and 
start portage and application )

Original comment by r3gis...@gmail.com on 30 Jan 2011 at 5:33

[GoogleCodeExporter]

@yuah
I personally feel that automatic resolving would be preferable, just because it 
just isn't a logical way to be forced to set the device for IP-probing... I 
mean, when this would be the problem, you can't expect an Android-user to know 
he/she should use the 'tun0' or 'rmnet0' interface as a mandatory setting. 
Maybe a combination ?? ;)

I think this would be a discussion for later... first, lets see if it's fixable 
without delving into the PJSip source. I hope that Regis (?) can cleanly fix it 
from within CSipSimple because that would yield the fastest results IMHO ;)

@R3gis.3R
First of all, thanks for this amazing piece of software! If I had the skills to 
do so, I would be glad to contribute. Since my programming-skills are limited 
to Python, I think it's a fair bet to say I wouldn't be of any help in that 
area ;). 

I checked the PJSip api and stumbled upon this: 
http://www.pjsip.org/pjsip/docs/html/structpjsua__transport__config.htm#a76cdb15
3b60fbbdbfd36ced9494bea0a. If I understand correctly, one can use the 
Transport-object to service one or multiple Accounts? Isn't setting public_addr 
attribute in the Transport class enough to advertise a specific IP as the 
origin/reply address?

And to be nostalgic; how does CSipSimple detect the public IP? :D

Original comment by j.stam...@gmail.com on 30 Jan 2011 at 9:03

[GoogleCodeExporter]

@j.stam : first, if you know python, you can write in almost any other language 
;) (I consider that's the master language ... somebody who codes python has the 
best skills to design the best apps... code less, do more :) ... I hate java 
and it's verbosity).

Then your right, there is an option in pjsip to configure public_address 
manually (if I do not mistake it can also be done per account directly). 
I can bind this setting in expert settings. The setting per account should 
already be set using expert account wizard and using "Force contact" field. But 
that's weird and not user friendly, I'd prefer to have a true auto-detection of 
the public IP, cause that's probably technically possible.

As for your last question : 
in fact it's pjsip that detect the "public IP". 
CSipSimple does only a weird and quick detection to detect if it should restart 
pjsip cause IP address has changed. I think that to fix this issue I have to 
fix that. (In fact I have to find a way to register to the fact VPN has been 
activated and then reload pjsip stack that will do the job automatically).
Now, how pjsip do... well that's pretty complicated process (I'm not sure that 
I've understood everything cause I debug that long time ago and didn't dive 
deeper in the process than what I needed) :
First it bind the server (open a socket). It read the local address on the open 
socket. At this point it knows the IP of the interface. That's pretty simple 
and extremely efficient. Doing that ensure to be safe to all strange routing 
rules. Cause that's up to the OS socket layer to resolve the route. Then 
reading the sock local IP is simple.
So that's the first step, when first registering it send this IP.
Then if you allow 'contact rewrite' (that's a trick used by pjsip guys), it 
deduce from result of the registration the public IP as seen by the server. In 
the OK to the registration the server replies with the IP it see for the 
client. If pjsip detect it is different from current announced IP it 
re-register with the new public address. That's a cool feature cause here no 
need of STUN or TURN. However some SIP server does not behaves properly 
regarding this method. And sometimes it's needed to tweak pjsip to change the 
way it re-register or to disable the feature.

Alternatively, it can use a STUN server. Here it simply ask the STUN server 
"what is my public IP?". If so it use provided IP address to register. The risk 
with that is to have the STUN server on another network than your SIP server. 
It occurs for enterprise IP-PBX when the STUN server is on public network and 
when you access to your enterprise IP-PBX from the local network... in this 
case obviously it's a bad idea to use the STUN server or you should have the 
STUN server on your IP-PBX/SIP server. It also occurs in some countries where 
the network is cut from the global network. For example if you are in China or 
Russia and try to use a STUN server in US or EU, and a SIP server in your 
country it will fail cause public IP seen by the STUN server is different from 
the public IP seen by the SIP server.
And finally, there is TURN and ICE features. I'm not an expert about these 
features. But their aim is to resolve public IP too...

So that's pretty complex as you can see, but it never involve the interface. 
And that's a really good thing cause interface is just hardware and we should 
use OS features that abstract hardware for us ! :)

Original comment by r3gis...@gmail.com on 30 Jan 2011 at 9:40

[GoogleCodeExporter]

Not sure if it helps but I'm running CSipSimple with Android 2.3.2 on a Droid 
over OpenVPN without issue.  The stock integrated SIP stack however won't 
connect over the VPN.

Original comment by escape2t...@gmail.com on 16 Feb 2011 at 6:25

[GoogleCodeExporter]

Issue 718 has been merged into this issue.

Original comment by r3gis...@gmail.com on 7 May 2011 at 3:54

[GoogleCodeExporter]

Issue 1015 has been merged into this issue.

Original comment by r3gis...@gmail.com on 3 Jun 2011 at 8:56

[GoogleCodeExporter]

I'm not sure whether to respond here, or in 1015, but I'm assuming if 1015 was 
merged here, I should respond here.

I have the VPN, and eth0 up, and Restarting the stack (going to settings and 
back) doesn't change the behaviour at all. Looking at the wireshark log of the 
packet, the packet comes from 10.8.0.13 (the vpn IP) to 10.8.0.1 (the vpn ip of 
the server), but in the sip register contact section, I get "[name]" 
<sip:[username]@[public IP]:38977;ob> instead of "[name]" 
<sip:[username]@10.8.0.13:[port];ob>. Because of the public IP in the contact 
section, the 200 OK response comes from the public IP of the server to the 
public IP of the phone. Sometimes this works, if they're actually real public 
IPs with no firewalling, but if you're in a random hotspot with a private IP, 
the 200 OK packet never makes it back to the phone.

Maybe the reason it doesn't work with force contact is because there's no way 
to put in the dynamic port # that pjsip happens to open for the connection (in 
the case above 38977), so Asterisk is trying to contact it at 5060, but pjsip 
is listening to some random port #.

I wonder if there's a way to tell Asterisk to ignore the contact IP, but use 
the packet IP instead?

There is still definitely a bug here somewhere, and it really needs to be fixed!

Original comment by andrew.h...@gmail.com on 3 Jun 2011 at 7:47

[GoogleCodeExporter]

Issue 833 has been merged into this issue.

Original comment by r3gis...@gmail.com on 4 Jun 2011 at 6:25

[GoogleCodeExporter]

r902 (that will be built tonight), introduce a new receiver that  ~should~ be 
aware about vpn connectivity changes.

As consequence it should at least restart the SIP stack when VPN connection is 
UP.

Then there is maybe remaining issue like the one of andrew about SDP and IP 
announced by pjsip to the remote party.
If you are experimenting this case of problem, I'd be interested by logs (see 
HowToCollectLogs wiki page). With infos on the different IP that lives on your 
phone (if possible, or at least the VPN network address area).

Original comment by r3gis...@gmail.com on 4 Jun 2011 at 6:27

[GoogleCodeExporter]

at r905, still same problem, public IP in the contact field, I enabled logging, 
restarted the sip stack, and then stopped logging. Log sent now.

IP addresses should be pretty obvious, 10.8.x.x is vpn, 142.x.x.x is public. 
Those are the only interfaces that are up (besides loopback).

Andrew

Original comment by andrew.h...@gmail.com on 6 Jun 2011 at 8:05

[GoogleCodeExporter]

Oh, I will add 10.8.0.1 is the server, 10.8.0.13 is the phone - 10.8.0.13 
hardly even shows up in the log file.

Original comment by andrew.h...@gmail.com on 6 Jun 2011 at 8:18

[GoogleCodeExporter]

Hi, i got exactly the same issue als Andrew.

The udp packets reach my asterisk server through vpn (server vpn ip 10.8.0.1) 
with correct source address (10.8.0.18), but asterisk tries to send packets 
back to the wrong contact ip (192.168.1.77 (wifi ip) in this case)

asterisk sip debug log:

<--- SIP read from 10.8.0.18:60027 --->
REGISTER sip:10.8.0.1 SIP/2.0
Via: SIP/2.0/UDP 
192.168.1.77:60027;rport;branch=z9hG4bKPjYeJsxeETbjbLVuOsBXVFE4a8oBRW5iv4
Route: <sip:10.8.0.1;transport=udp;lr>

HTH

Original comment by phoenix....@gmail.com on 8 Jun 2011 at 12:46

[GoogleCodeExporter]

It would be enough i think, if under "Force contact" one could supply an ip 
addres only (or interface name) and the dynamic port is added automatically.

Original comment by phoenix....@gmail.com on 8 Jun 2011 at 1:21

[GoogleCodeExporter]

The "Force contact" field does not work. In the contact info sent normally, 
there's the port number that pjsip has opened for incoming connections, and it 
is not 5060, and is random. If you omit the port number from the contact field, 
asterisk tries to contact the phone at 5060 when a call comes in (or similar), 
and pjsip isn't listening to that port, so nothing happens. The force contact 
field is on the right track, but there needs to be a way to tell it to append 
the port number to the forced contact address.

Original comment by andrew.h...@gmail.com on 8 Jun 2011 at 4:06

[GoogleCodeExporter]

Pardon me if this comes off as dismissive, but why should CSip need to be aware 
of a VPN at all? I have CSip running on two devices: a Xoom and a Nexus S, both 
via daemonized OpenVPN. Choppy sometimes, but my asterisk server is listening 
only on the private IP, and I was able to register without any problems at all. 
Whenever the VPN connects, my SIP registers.

Could anyone please explain to me: What is the logic of making CSip deal with 
the VPN directly? Isn't that what the OpenVPN client is for?

Original comment by josh.lin...@gmail.com on 21 Jun 2011 at 6:39

[GoogleCodeExporter]

Josh - I'm running CSipSimple on a Motorola Droid with Android 2.3.2 over an 
OpenVPN network and like you, everything works fine.  That wasn't the case with 
earlier versions of Android and some SIP clients still don't work with Android 
2.3.2 over the OpenVPN.  

For example, the stock integrated SIP capability won't work over the OpenVPN 
tunnel.  
From thread posts I've read, it sounds like the non-working SIP stacks are 
sending all IP traffic over the Wifi or 3G (whichever is active) and ignoring 
the VPN.

Unrelated to this ticket but it would be nice if we could have CSipSimple 
auto-launch the VPN for making a call and then disconnect afterward.  :)

Original comment by escape2t...@gmail.com on 21 Jun 2011 at 6:56

[GoogleCodeExporter]

Connect to your vpn from behind a NAT, then tell me og your sip still
registers.  Or, on your asterisk server, do a sip show peers. Is your phone
registering with the vpn ip or the public one?

I am going to take a look at the  code in a few weeks myself and just fix
it, seeing as no one else seems to even get the issue.

Original comment by andrew.h...@gmail.com on 21 Jun 2011 at 7:25

[GoogleCodeExporter]

Escape: Thanks, that is exactly what I wanted to know.
Andrew: "sip show peers" gives me the private (VPN) IP, as I expected it would. 
Is this undesirable?

It isn't exactly related to CSip, but is related to this thread, so I'll throw 
it out there in case it helps anyone add OpenVPN functionality to CSip: OpenVPN 
needs engine support in OpenSSL (AFAIK). I went through great pains to patch 
together a working version of OpenSSL suitable for use with OpenVPN. I'm not 
sure if you would have to do the same thing to add such support to CSip, but in 
case you do, I've put together a how-to for adding the engine support back into 
OpenSSL 1.0.0a (the version currently packed in AOSP). If anyone is interested, 
PM me and I will send you links and give explanations where they are needed so 
I don't further clutter this thread.

Thanks for all your hard work!

Original comment by josh.lin...@gmail.com on 22 Jun 2011 at 3:35

[GoogleCodeExporter]

Yes, that is desireable. Hmm, why does it register with the VPN ip for you,
but not for me? What revision are you running?

Original comment by andrew.h...@gmail.com on 22 Jun 2011 at 3:48

[GoogleCodeExporter]

Yes, that is desireable. Hmm, why does it register with the VPN ip for you,
but not for me? What revision are you running?

Original comment by andrew.h...@gmail.com on 22 Jun 2011 at 3:48

[GoogleCodeExporter]

Version of asterisk? 
Asterisk 1.8.4 built by joshl @ JoshAsterisk on a x86_64 running Linux on 
2011-05-24

CSip? r933-tls

I have asterisk configured to only bind to the private (VPN) IP address. My 
thought process was to set CSip to use a private IP (or DNS that resolved to a 
private IP) and let the routing table do all the work of directing the packets 
over the VPN, which runs as a separate daemon.

Original comment by josh.lin...@gmail.com on 22 Jun 2011 at 4:05

[GoogleCodeExporter]

Ok, my setup is slightly different. My Asterisk box has a vpn, and a regular
interface, and stuff connects to it on both, so I can't limit it to only
listen to the VPN IP.

I also thought that CSip would use the private IP, if I tell it to connect
to asterisk on the asterisk server's private IP. The IP packet headers are
actually correct, but in the SIP contact field, CSip puts in the public IP
of the phone, and then asterisk switches to using that IP to talk to the
phone. So from phone -> asterisk, it actually goes over the vpn, but from
asterisk -> phone, it does not, it goes over the public network, so if the
phone's "public" IP is actually behind a NAT, the connection doesn't work.
Do you have something in your asterisk config (or do you know of a sip
option) that makes asterisk ignore the sip contact field, and use the source
IP address of the packets instead? I looked through all the sip options, I
don't see anything like that at all.

The other funny thing is I swear, for a while, it actually randomly was
working properly, until I rebooted the phone, and it seems the wifi became
the first interface in the list or something again, and it switched back to
using that IP in the contact field, instead of the VPN IP.

I have other asterisk servers that connect to this one over the same vpn,
and everything works fine. All that traffic goes only over the VPN
connections. I've also had desktop SIP phones connected over the same vpn as
well (through a linux box at the other side being the VPN client and
router), and that works fine too. The problem is just that CSipSimple picks
the wrong IP address to put into the contact field when it registers. As I
mentioned before, using the "force contact" field works, except then the
port number (which is dynamic) is missing, and asterisk tries to contact
CSipSimple on 5060, and CSipSimple isn't listening on that port. My plan was
to just fix the code that does the "force contact" handling to properly
include the port number, then it should work.

My asterisk is Asterisk 1.6.0.6.

I spent a few hours last night getting eclipse and the android SDK setup,
and got CSipSimple checked out of svn last night, but I didn't get to the
point of extraacting the pjsip library from the .apk file (I don't see a
point in rebuilding it as I'm not changing pjsip), and thus never got the
project to build yet. Just getting the environment took longer than I
expected, but I did expect it to take a while - it always does getting a
build environment setup.

Andrew

Original comment by andrew.h...@gmail.com on 22 Jun 2011 at 7:44

[GoogleCodeExporter]

Andrew, I just tried to PM you, but I can't figure out how to see your full 
email addy, and I am therefore not convinced that you can see mine. My last 
name is Lindsay, so I figure you can fill in the gaps and email me if you want 
to continue talking. For now, here is the link for patching the AOSP OpenSSL to 
accommodate OpenVPN. Not sure if you'll have to go this far, and most of it is 
probably OFN to you, but it may help:
http://www.joshianlindsay.com/index.php?id=113

What is the extent of your control over the various parts of the system? If 
OpenVPN were to be integrated into CSip, would it be a separate package bundled 
in the same APK? I assume it would still be native.

I know just enough about asterisk to be a threat to my own sanity. So I 
intentionally setup my system to minimize complexity in that corner. I'm 
learning more about it each week as I have to deal with the NAT/SIP problem for 
other systems I work with.
For what it's worth, my setup didn't have any problems with NAT/SIP for the 
reasons you mentioned. But it did require much more work at the handset.

Moderator, I won't be miffed if you nuke my posts. Sorry for cluttering your 
board. :-)

Original comment by josh.lin...@gmail.com on 22 Jun 2011 at 9:31

[GoogleCodeExporter]

Yes, we can take this discussion offline...

I will send you an email.

Original comment by andrew.h...@gmail.com on 22 Jun 2011 at 9:36

[GoogleCodeExporter]

> Moderator, I won't be miffed if you nuke my posts. Sorry for cluttering your 
board. :-)

Don't worry, that's fine :). Do not hestitate to share you findings. It is 
really welcome :D

About the fact to integrated OpenVPN to CSipSimple, I think that anyway it 
could/should remain two separate apk (in order to release it for mainstream 
users). 
I think that Android is enough well designed  to allow apps to interact with 
each others - even for native library -. 
I'm currently trying to do something to allow an app to enrich native features 
of pjsip such as codec, video, TLS, ZRTP and so on from different apk. 
It should allow to add extras features dynamically and easily for mainstream 
users.

Original comment by r3gis...@gmail.com on 22 Jun 2011 at 9:42

[GoogleCodeExporter]

Yeah, I was also going to say, I don't see the need to integrate openVPN
with CSipSimple. I'm running CyanogenMod. It has integrated OpenVPN support.
I'm not sure if that's part of Android Gingerbread - I think it's their
addon, but it's there, and all works right out of the box, so that wasn't my
plan. I wonder if that has something to do with why it works differently for
me than it does for you - OpenVPN is somehow setup differently in
CyanogenMod than you have it setup... ? Hmmm...

Andrew

Original comment by andrew.h...@gmail.com on 22 Jun 2011 at 9:58

[GoogleCodeExporter]

>>CyanogenMod [...] has integrated OpenVPN support.
Yes. The biggest obstacle to making it work is having a kernel with tunneling 
support, or the equivalent kernel module. Most of the carriers want this 
functionality removed, because then they can charge their customers for 
tethering support (which also relies on tunneling support). 
For the OpenSSL engine support, one could compile OpenVPN as a static binary 
and wrap a completely different version of OpenSSL into that. It makes the 
binary much larger, but it does the trick, and doesn't require that you replace 
your existing OpenSSL installation (which is otherwise adequate, IMO).

>>I'm not sure if that's part of Android Gingerbread
It isn't. :-(
However, I believe the source code that I used is very recently diverged from 
that which is in use by CM7. So for all intents and purposes, it can be treated 
the same.

So from what I gather from you guys, it would be better to extend CSip to 
manage OpenVPN. Currently, I simply start it as a daemon at boot time, and it 
connects opportunistically whenever the server's IP is accessible (ie, whenever 
a data connection exists). This works very well for my purposes because I only 
have one VPN that I care to use. But if I had several, a management app would 
be called for. I foresee myself writing one in the near future, and I plan to 
continue using CSip for VoIP. So let me ask you guys this:

How should CSip deal with OpenVPN? Should the user be able to bind different 
VPNs to different accounts? Should the VPN control feel like a global bolt-on, 
as the secure transport options presently do? What specific features are 
desirable?

Is it a bad thing if there exist features in CSip that require the phone to be 
(rooted and include busybox) in order to be used?

I'm willing to contribute to this project, because I get a large amount of 
utility from these tools. But if I'm going to spend the time to do it, I'd like 
it to be well done the first time.

Original comment by josh.lin...@gmail.com on 22 Jun 2011 at 10:29

[GoogleCodeExporter]

I wish it would look at the server IP, and at the local interfaces, and if
any of them happen to be on the same subnet, it should use the IP address of
whatever interface that happened to be for the contact info. From previous
discussion, this seems that it should be the job of pjsip, not CSipSimple,
but it apparently doesn't work. The real solution is to fix it there, but
for now, I'd be happy just kludging it in CSipSimple temporarily, for
myself.

That would solve my simple problem, but would still leave a gap for someone
with multiple VPN connections, and possibly connecting to things that are
behind the VPN, not on the VPN itself. It seems there needs to be a way to
tie a certain SIP account to a certain interface, or possibly group of
interfaces. Then of course the next problem that comes up is with multiple
VPNs, which order will they come up in? What if some are accessible and some
not? Can (or should) one specify a unique interface name for each VPN, so
regardless of order, or availability, VPN connection X always appears as
interface tap / tun X? This is really a question for a VPN management app I
guess, but needs to be considered in what the best way forward in CSipSimple
is.

Andrew

Original comment by andrew.h...@gmail.com on 22 Jun 2011 at 10:58

[GoogleCodeExporter]

Heh, now that I have the build environment all setup, ready to start making
some code changes, and now it's connecting from the VPN IP - I don't get it.
I'll have to check multiple times in the next few days if it continues to
register from the correct IP. I seem to recall this happening before, then
suddenly it stopped using the VPN IP. UGH I hate these kind of debugging
problems - the intermittent problem is the worst to solve.

Andrew

Original comment by andrew.h...@gmail.com on 23 Jun 2011 at 7:52

[GoogleCodeExporter]

Yup, and of course, now that I'm actually on vacation, it's back to it's usual 
tricks of registering with the wrong IP address again :(

Now I can try to change the code on my dev box remotely, or setup this laptop 
as a dev box (which I don't think is going to work well, as this machine is 
slow, and low on memory).

Could someone just change the code for the force contact so that it just 
replaces the IP address, but inserts the right port number on its own? Or is 
there some way I can force it to a certain port so that I can just type in a 
force contact myself and have it work?

Andrew

Original comment by andrew.h...@gmail.com on 28 Jun 2011 at 1:21

[GoogleCodeExporter]

My simple setup is as follows - I have a local Csipsimple account and an 
Openvpn tunnel. When I call another client direct via Openvpn tunnel (Openvpn 
tunnel provides several routes) Csipsimple reports the wrong address to the 
other client(Twinkle, testing zrtp).

Basically the correct behavior would be that when Csipsimple/pjsip starts or 
registers the accounts, it notes all the routes on the system (ip route) and 
all the interfaces and their addresses (ip addr). When a call goes out which 
happens to be with a destination address that routes out via a non-default 
interface, the call should be sourced with the address of that non-default 
interface (v4 or v6). This should work with multiple OpenVPN tunnels too.

My hunch is that to manage OpenVPN tunnels might be too awkward. Tunnels can 
fail and reconnect with a different address. I don't know if it's possible on 
Android but the best idea would be to get an triggered event when an interface 
changes and then accounts are re-registered.

Original comment by fossm...@gmail.com on 16 Jul 2011 at 4:07

[GoogleCodeExporter]

Ok, I'll try again to re-explain what should be "the correct behavior".

Keep in mind that pjsip is cross platform and that saying "detect system route" 
make absolutely no sense.

In fact what it does is much more simplier, when pjsip starts, it simply bind 
sockets to remote party and then automatically detect its "public" ip from the 
local part of the bound socket.
Well what could break that :
 * use of stun
 * another account that get a route to public network and that starts before the vpn account.
Both problem will be fixed when pjsip-2.0 will implement per account nat 
resolution (there is a tracking issue on this issue list about that).
You can also disable stun,and disable "allow contact rewrite" for this account 
to avoid that.

That said, if pjsip starts when your VPN is up, it will work as expected. The 
public IP will be your IP in vpn network. It can't fail. It just about binding 
sockets, and if the core network layer of the system bind it correctly, I don't 
know why it would fail.

Then there is another problem... detect when VPN comes up. That's more 
complicated since there is no public API on android to know that. I recently 
added the most common interface (the one that is actually implemented in 
private api - I get that from AOSP source code to be notified when VPN network 
comes up and then restart the sip stack and re-register all accounts).

If it does not work, it means that the ROM you are using implements other way 
to notify application that VPN is up. If so, let me know, try to find infos 
about what intent I should listen and when I should restart, I'll add that, no 
problem :).

You can validate it comes from the fact it does not restart simply by manually 
go in settings and press back (closing settings view automatically restart the 
stack).
If after that when your vpn is up it works, it's just about vpn up/down 
detection. If it still does not work, it's either about the fact the core 
network is not able to resolve correctly routing, or about the fact there is 
some stun feature or some other account that set up the global public IP of 
pjsip stack (and as I said, read and follow the issue 345 about that)

Original comment by r3gis...@gmail.com on 16 Jul 2011 at 10:13

[GoogleCodeExporter]

Ok, I ran another test:
For good measure I stopped all possible services on the android phone: Openvpn, 
CSipSimple. Btw, even though I stopped CSipSimple from Application Settings -> 
Running services when I logged in with root shell via adb, ps showed that 
'com.csipsimple' was still there. I killed it to have it gone. Bottom line, at 
the start of the test nothing was running.
I have only one local account configured in CSipSimple. Zrtp is turned on. No 
servers, no STUN, ICE or TURN. Absolutely no nat is involved in network 
configuration. 

1. Started the Openvpn tunnel. Tunnel came up, all good.

2. Started CSipSimple.

3. Made a call to the Twinkle client over OpenVPN. Call starts but Twinkle 
still reports that it comes from the address that's assigned to the Android 
phone wireless interface. Twinkle can hear audio from the phone, but the phone 
can't hear audio from Twinkle. Zrtp doesn't work of course. Tcpdump and tshark 
output shows that CSipSimple is reporting (in sip headers) its address to be 
the one from the wireless interface and Twinkle starts sending rtp to that 
address (unsuccessfully). In other words, port 5060 traffic itself is sourced 
and destined with the correct addresses, but address reported inside those 
packets (for rtp to work) is the wrong one.

What I am using:
CSipSimple-r986-tls.apk from http://nightlies.csipsimple.com/tls/
Phone - Android 2.3.3, Kernel 2.6.29.6, CyanogenMod-7.0.3-Heroc (for HTC Hero)

Am I doing something wrong?

Original comment by fossm...@gmail.com on 17 Jul 2011 at 7:31

[GoogleCodeExporter]

Here's a paste of tshark dump on the first packet that goes from CSipSimple to 
Twinkle.
http://friendpaste.com/JTl5Aj5Titoi9TCadFlns

Here's another paste of tshark dump on the first packet from CSipSimple to 
Twinkle.
http://friendpaste.com/6Tcu8NQAq89PuX3KV0m2Rb
This time around I changed Twinkle address to be different. But most 
importantly I chose the Expert Wizard and made sure Allow Contact Rewrite, 
Force Contact were set to the tun0 address and user on the phone. I also had to 
set Account id to something, otherwise Expert Wizard didn't allow me to save 
for local account.

The result is the same, Twinkle tries to send audio to the wireless address.

Original comment by fossm...@gmail.com on 17 Jul 2011 at 7:43

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

If you want to be sure pjsip will not rewrite the contact header... you should 
disable "Allow contact rewrite" option and not leave it enabled.
Is there another account enabled ?
Also, what is really interesting is not the invite in this case, but what comes 
before. Trace from pjsip when it detect the public IP.

In your case it probably does before, for example while registering somewhere. 
So, traces from the software are much more relevant in this case to know what 
happens and why this "public ip" is used ;).

Actually if you really want to have a local account, a better idea would be to 
create a local account with the "local" wizard. 
If you do using the expert one, you must absolutely exactly know what you are 
doing, and you must know where you bind your local port of the client to set 
the account id to the correct thing. (for example, by default, if you don't 
change the local bound port, it is set to listen on random port, which mean 
that your local sip port is something random... and so it's hard to set in the 
account id ;) ).

Original comment by r3gis...@gmail.com on 17 Jul 2011 at 8:10

[GoogleCodeExporter]

So, rather than just mentioning binding the local port, and making it
not random, how about actually saying how to do that?

Original comment by andrew.h...@gmail.com on 17 Jul 2011 at 8:22

[GoogleCodeExporter]

In expert settings mode (see wiki about that), in Settings > Network > UDP 
port. By default it's set to 0 (which mean random), set to 5060 if you want to 
set up local port to a fix port.

*However*, again, it's better to create a local account using local wizard if 
you actually want to create a local account. 
So I'd not advise to change the port but rather to use this local wizard 
instead (that's why I didn't entered details about this point !!).

Local wizard is the only wizard that is not an expert wizard behind the scene. 
It does something special in pjsip saying that this is a local account. 
As consequence, pjsip will automatically set the port of the account id with 
the one it has bound locally. 

Just another point... actually what break up audio path is not the account / 
contact id. It's the info in the SDP.

But anyway, again, what is important to understand why pjsip choose this public 
ip, it's what happen before. Logs of pjsip are pretty clear about how it gets 
its public IP. And with limitation I previously explained (no per account NAT 
support), it should be possible to control (either if it's a local or a remote 
account).

Original comment by r3gis...@gmail.com on 17 Jul 2011 at 9:00

[GoogleCodeExporter]

>Is there another account enabled ?
No. The local account is the only one. (I haven't set anything else up.)

I only changed the local account with the Expert Wizard for the last tshark 
dump. So all previous tests I did were with an account that was setup with the 
simple Local Wizard.

So I went to the CSipSimple settings and turned loglevel to 5. Then I shut it 
down, killed the remaining process via adb shell and turned on adb logcat. Then 
I started CSipSimple and here is the output for that:

http://friendpaste.com/27pPmU0RhSkkpkfsFV1Sdj

Somewhere in the middle it shows that pjsip chooses the wireless interface 
address for sip. 

I'll be happy to help with any other testing.

Original comment by fossm...@gmail.com on 17 Jul 2011 at 9:00

[GoogleCodeExporter]

Oh, ok, somehow I missed that UDP port number setting before (or I was
never looking in "settings" but in the account settings). If I can
force the port, then I can force the contact info field and just use
that to get around the problem for now!

I still do have the dev environment setup, and will have a look at the
code at some point and see if there's a better way to fix the problem,
but this will be a quick fix in the meantime.

Original comment by andrew.h...@gmail.com on 17 Jul 2011 at 9:07