#390 OpenVPN support

[Anonymous]

Originally created by: yuah.p...@gmail.com
Originally owned by: r3gis...@gmail.com

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?

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

Summary: OpenVPN support
Labels: -Type-Defect Type-Enhancement
Status: Accepted

[Anonymous]

Originally posted by: wheresau...@lavabit.com

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?

[Anonymous]

Originally posted by: wheresau...@lavabit.com

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.

[Anonymous]

Originally posted by: yuah.p...@gmail.com

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.

[Anonymous]

Originally posted by: yuah.p...@gmail.com

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 ?

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 588 has been merged into this issue.

[Anonymous]

Originally posted by: j.stam...@gmail.com

It seems that csipsimple suffers from the same bug(/feature) as SipDroid. See: https://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.....

[Anonymous]

Originally posted by: yuah.p...@gmail.com

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...

[Anonymous]

Originally posted by: r3gis...@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

@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 )

[Anonymous]

Originally posted by: j.stam...@gmail.com

@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/structpjsuatransportconfig.htm#a76cdb153b60fbbdbfd36ced9494bea0a. 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

[Anonymous]

Originally posted by: r3gis...@gmail.com

@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 ! :)

[Anonymous]

Originally posted by: escape2t...@gmail.com

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.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 718 has been merged into this issue.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 1015 has been merged into this issue.

[Anonymous]

Originally posted by: andrew.h...@gmail.com

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!

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 833 has been merged into this issue.

[Anonymous]

Originally posted by: r3gis...@gmail.com

[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).

[Anonymous]

Originally posted by: andrew.h...@gmail.com

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

[Anonymous]

Originally posted by: andrew.h...@gmail.com

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.

[Anonymous]

Originally posted by: phoenix....@gmail.com

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

[Anonymous]

Originally posted by: phoenix....@gmail.com

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.

[Anonymous]

Originally posted by: andrew.h...@gmail.com

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.

[Anonymous]

Originally posted by: josh.lin...@gmail.com

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?

[Anonymous]

Originally posted by: escape2t...@gmail.com

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.  :)