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

@fossm : my bad : I forgot that, but when used as a local account, pjsip has no 
way to detect the correct public IP. 
The method described by Andrew is better if you'd like to have a local account. 
If you have a sip registrar on your vpn, pjsip will resolve the public IP 
correctly when registered. If not, you have to do the following (to sum up):

 * Setup the local UDP port of the app (Settings > network > udp port)
 * Create an expert account with a display name and setup as local id : you@YOUR_VPN_IP:UDP_PORT_OF_PREVIOUS_POINT.
 * disable "enable contact rewrite" in this case
 * normally it should not cry for any other missing params (else let me know, I'll fix that ;) ).

The reference in FAQ of pjsip may be helpful too : 
http://trac.pjsip.org/repos/wiki/FAQ#multihomed 

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

[GoogleCodeExporter]

It's still not successful.

The only difference from your instructions was with setting up your local id; I 
had to put it in this format: '<sip:somename@10.255.1.4:5060>' I tried a 
different port also but that didn't make a difference. "Via" header in the 
packets still went with wireless address (but a correct port number). 
Connection information headers also have the wrong ip.

I restarted the app as always.

Would it be a good idea (or possible at all) for local account creation Wizard 
to have interface name field and force pjsip to use an ip like that?

Original comment by fossm...@gmail.com on 17 Jul 2011 at 10:15

[GoogleCodeExporter]

I have finally gotten around to adding a forced bind address (per account, 
kindof), and IT WORKS! If I turn off the forced bind address, it tries to 
(incorrectly) use the 'public' ip address, and cannot register. When I put in a 
forced bind address, everything works correctly.

Before I release a patch, I'd like to get some feedback from other people, as 
well as the main developer as to what functionality would be useful, and some 
input on a few things. 

Right now I have bind address and public address in each account, which allows 
each account to use a different interface if required. The bind address must be 
specified explicitly, which might be tricky if you have dynamically assigned 
VPN ips. 

QUESTION 1:
Would it be useful to be able to specify a wildcard in the bind address, and 
have csipsimple look at all the interfaces on the system, and match one to the 
wildcard? This way you could specify "bind to 10.8.0.x" and at runtime, 
csipsimple will figure out what the actual address in that range is and bind to 
it (or throw an error if there is no such interface up).

I haven't done any testing with more than one account active at a time. 
Essentially what I do is if the account is forcing UDP, and forcing a bind 
address, I remove the existing default UDP transport, and make a new one with 
the forced parameters in its place. This could severely break if you have 
multiple accounts active at the same time, and some of them are already using 
the default UDP transport. I'm guessing that if an account needs custom 
transport parameters, it would be better to just make a new transport for that 
account, and leave the default one alone. 

QUESTION for the main developer:
Do I need to remove a custom transport if the account later goes inactive?

QUESTION 2:
Do people use multiple accounts active at the same time?

QUESTION 3:
Would it also be useful to be able to force a port per account? This might be 
necessary if you need to know what port number each account is using on the 
csipsimple side, rather than having "custom" transports use a random address 
(as only one transport can use the default port, if specified, in the main 
settings).

Andrew

Original comment by andrew.h...@gmail.com on 21 Aug 2011 at 3:10

[GoogleCodeExporter]

Oh, perhaps one problem I just discovered, when I build the app, I don't seem 
to get any audio to come out of the device anymore - the mic works fine, but 
nothing from the speaker. Don't know why yet.

Original comment by andrew.h...@gmail.com on 21 Aug 2011 at 3:58

[GoogleCodeExporter]

Ugh, of course the problem is now the RTP transport still binds to the wrong 
address!!

GRRR, the PJSip stack sucks when it comes to multihomed boxes :(

Original comment by andrew.h...@gmail.com on 21 Aug 2011 at 4:38

[GoogleCodeExporter]

Andrew:
Your audio problems are likely RTP related. Tell me: is the VoIP server under 
your control? If it is, I can give you help debugging.

To answer your question about multiple registrations: yes. Some users do 
register at multiple servers at the same time.

I can already force a port for a given account by appending ":<port>" to the 
SIP registration address. Is this inadequate for some reason?

Original comment by josh.lin...@gmail.com on 21 Aug 2011 at 4:57

[GoogleCodeExporter]

Ok, I fixed the RTP ip address issue now too. There is something seriously 
wrong with the way pjsip was designed!!!

Original comment by andrew.h...@gmail.com on 21 Aug 2011 at 5:10

[GoogleCodeExporter]

In response to comment 56 by Josh:

That is the port you are connecting to on the server. I'm talking about the 
port that pjsip opens for the connections coming back to it. It can either be 
random (the way it is by default), or currently specified for all accounts in 
the application settings when you put it in expert mode. I thought it might be 
possible to specify which port was opened for each account (perhaps useful in 
registration-less setups), but now with this latest development with having to 
force the bind IP for the media transport too, and there can only be one media 
transport (it appears), really breaks being able to control all of this on a 
per account basis.

Looks like now that if you need to force the bind IP, it pretty much has to be 
a global setting that affects all accounts - a rather shortsighted design in 
the pjsip stack!

Each account is able to have a separate sip transport associated with it (UDP, 
TCP, TLS, etc), and when you create that transport, you can force what IP and 
port it is bound to (aka, to force to use VPN ip, the whole point of this 
issue). There is only one media transport though, and it applies to all 
accounts, so if you need to force a VPN ip on that transport, now all accounts 
have to use that transport. Either I'm missing something about how pjsip works, 
or that is not a very good design at all!

Original comment by andrew.h...@gmail.com on 21 Aug 2011 at 5:20

[GoogleCodeExporter]

>>I'm talking about the port that pjsip opens for the connections coming back 
to it.
Ah. That makes sense now. 

I haven't tried digging into PJSIP yet. I've been putting it off until last 
week when I started poking around in the java interface for it. So I probably 
can't help you too much there (yet). I was evaluating ZORK (which is built off 
PJSIP).

If you are testing your work with asterisk, you can restrict RTP ports to your 
clients, and even prevent them from trying to establish RTP connections 
directly to one-another (sip.conf => directmedia = no). This puts asterisk in 
the RTP audio path, and solved all of my NAT issues. It doesn't help your SIP 
problem, unfortunately, but it might make your life easier. I'm using the 
asterisk 1.8 branch.

Good luck. :-)

Original comment by josh.lin...@gmail.com on 21 Aug 2011 at 7:11

[GoogleCodeExporter]

Yeah, the java front end on csipsimple is a bit complicated, and add in the 
wrapper around the pjsip library, and it takes quite a while to do some very 
simple things. Took me about 5 hours to generally figure out how it works, and 
figure out enough to add 2 settings to the expert account wizard for the bind 
IP and the public IP (and the database, and update the schema, and on and on), 
and probably another 3 or 4 to ponder how to actually implement it (per 
account, vs overall), and yet  more to actually make it work.

I am using asterisk, and yes, I force all the RTP to go through asterisk. That 
combination, along with VPN connections, is extremely powerful and versatile!

Well, my problems are essentially solved now, what remains is to make it just a 
little more nicely implemented so it's useful to more people!

Original comment by andrew.h...@gmail.com on 21 Aug 2011 at 7:20

[GoogleCodeExporter]

i use freeswitch over vpn, im sure to nat everything on its way out of the 
phone (for layer3), and on the sip-side  (application layer) freeswitch has 
it's own way to deal with nat... works fine =]

Original comment by grndcntr...@gmail.com on 2 Sep 2011 at 9:23

[GoogleCodeExporter]

Hi andrew,
in response to Comment 56:

i would highly appreciate that you release a patch as soon as possible, as i am 
traveling a lot and it would be a huge benefit for me, even if i would have to 
enter a new ip address each time.
I used an iPhone before and this was exactely the way it was done in the SIP 
app there.

Question 1:
A wildcard IP would be very nice, as for some reason i am unable to assign a 
fixed ip in my network but it is always in the same subnet.

Question 2:
i do not

Question 3:
see question 2

Brgds Fabio

Original comment by lombi...@googlemail.com on 4 Sep 2011 at 11:47

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I will work on adding the wildcard for the IP address (just need to
lookup how to get a list of active interfaces from android), and try
to get a patch published as soon as possible (later today, or maybe
tomorrow).

It's been working great for me - the odd time it spits up a message
that it can't bind to that IP because no such interface exists (when
the VPN disconnects), then when it reconnects, csipsimple registers on
its own. It works quite well.

Andrew

Original comment by andrew.h...@gmail.com on 5 Sep 2011 at 5:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Andrew,

as I am still highly interrested i wrote a function to get the VPN IP address.
I use a wildcard on the interface name matching tun[0-9].
I think this is better than using the wildcard function on the ip.
It works assumed the tun interface matches the naming convention tunX.
Mine is name tun0.

Brgds Fabio

Original comment by lombi...@googlemail.com on 7 Sep 2011 at 12:08

Attachments:

• getVPNIpAddress.java

[GoogleCodeExporter]

Hi

Sorry for not getting the patch out sooner, but something came up
(raid controller went berserk, working on getting a few TB of disk
back online). I'll have a look at your code tonight hopefully. Last
night I was looking at the java.net.NetworkInterface class on the
android developer docs. Looks like it has pretty much anything needed!

Andrew

Original comment by andrew.h...@gmail.com on 7 Sep 2011 at 4:13

[GoogleCodeExporter]

Hi Andrew,

could you maybe send me your changes via mail as far as they are? I've a bit 
time now to work on it.

Fabio

Original comment by lombi...@googlemail.com on 9 Sep 2011 at 10:45

[GoogleCodeExporter]

Sure, I was going to post a binary at least, as I'm not going to have
time to work on it this weekend either, but I put a diff there as
well.

http://www.ece.ualberta.ca/~hakman/CSipSimple

Andrew

Original comment by andrew.h...@gmail.com on 9 Sep 2011 at 5:39

[GoogleCodeExporter]

Oh, and also, just so you know, there's a planned network outage where
that's sitting tonight Sep 9th from 22:00pm to Sep 10th 7am MST (GMT
-5), so if that link is unavailable tonight, that's why. It will be
back when the network is back.

Andrew

Original comment by andrew.h...@gmail.com on 9 Sep 2011 at 5:43

[GoogleCodeExporter]

Hi Andrew, thanks for sharing and great work! I had a look at your code. I see 
you force the bound and public address for pjsip. I read the documentation here 
http://www.pjsip.org/pjsip/docs/html/structpjsua__transport__config.htm#a76cdb15
3b60fbbdbfd36ced9494bea0a but i am not so sure what's the difference between 
public and bound address. However.
don't you think it wouldn't be sufficient to just take the IP address of the 
tun Interface, set bound and/or public address (depending on whats really 
needed for a working OpenVPN connection) and create a switch like "Connect 
through OpenVPN"
I see no clue in setting the whole ip stuff manually. OpenVPN uses tun Kernel 
module and I am pretty sure the interface is called /dev/tunX for all android 
devices.

Fabio

Original comment by lombi...@googlemail.com on 9 Sep 2011 at 7:19

[GoogleCodeExporter]

Yes, but I was thinking in the beginning that you could have multiple
VPNs and multiple accounts, and hence would want to bind each account
to a different interface, so the easiest way was to specify the ip
address to bind to. Then when I was actually doing the pjsip part, I
noticed that it seems you can only have one global media transport, so
if you force the bind address for one account, all accounts now use
the same media transport, so it's pretty useless for a multi account /
multi vpn setup.

My way was more generic (if it was possible, which it seems not with
pjsip the way it is),  your way is easier!

The bind address forces which interface on the local device the socket
will be bound to (for multihomed, like in our case the vpn vs wifi
interface). The public IP is for publishing the ip address of a NAT
router when you are behind it, and the NAT router is setup to forward
all SIP traffic to you. So say the nat is 192.168.10.x, the phone has
the address 192.168.10.2, and the router's public IP is 123.45.67.8,
and the router is setup to forward all sip traffic to 192.168.10.2.
You can't bind to 123.45.67.8 as that isn't a local interface on the
device, but you do want to publish that as your contact address, as
the router will look after getting the traffic to you. That's the
purpose of the "Public" field. It isn't useful to me (as the VPN
eliminates all the NAT entirely), but I figured I'd add it at the same
time. Might be useful for some.

Andrew

Original comment by andrew.h...@gmail.com on 9 Sep 2011 at 9:30

[GoogleCodeExporter]

Hi Andrew,

i tested your patch yesterday. I set the bound_addr to my vpn ip and left the 
public_addr unset. Seems to work pretty good! Very fast connecting and good 
audio.
I implemented this for me hardcoded, just to act like this:
Is there a openvpn interface?
 if yes: set bound_addr to vpn ip
 if no: leave everything as it is
I thought about creating a checkbox in expert mode but i am pretty sure as this 
is only a temporary fix as long as there is no clean way of openvpn support, 
its better to leave it like this without database changes for easier patching 
against never revisions.
You can find binary and diff here:
http://lombardi.mobi/csipsimple/

Greets Fabio

Original comment by lombi...@googlemail.com on 10 Sep 2011 at 11:25

[GoogleCodeExporter]

Andrew and Fabio thanks a lot for the patches, sounds great.

Sorry for the big delay. I'll include this setting in the future dev release 
(based on psjip-2.0) that will now support bind and pub uri a better way. 
It will also has per account transport creation for media which should be 
better. :)

So it will be integrated really soon. Before, I'll do a stable release without 
the fix, and then it will be integrated with your modifs. It's indeed a good 
idea to add a checkbox in expert mode to use bound_addr as the vpn iface if 
available and add the bound_addr as an editable entry if this checkbox is not 
activated.

Original comment by r3gis...@gmail.com on 7 Nov 2011 at 11:01

[GoogleCodeExporter]

@35, 37

How ought one frame a question to hosted PBX providers to solicit what info 
they need to modify their PBX asterisk flavors to reduce the masochism of 
sip/rtp conveyed solely through openvpn on same serv server to android client 
(whose phone 3g/4g is suffering carrier Nat, where both the IP address, public 
interface/private interface, change frequently, seemingly to break such uses 
even when attempting to hold open with keep alive). Verizon Wireless.. does 
offer static IP address on 3g/4g interface

Original comment by fantasti...@live.IE on 11 Nov 2011 at 3:00

[GoogleCodeExporter]

rtp_bound_address (and public address but should be optional in vpn case) are 
now part of the latest nightly build's expert wizard settings.

Once I'll release my other project to automatically turn on or off settings (in 
this case csipsimple account config) based on conditions (in this case vpn 
connectivity). It will allow to have some complete solution.

For now, with the account config + home screen widget it should at least allow 
to workaround.

Original comment by r3gis...@gmail.com on 14 Jan 2012 at 12:21

[GoogleCodeExporter]

Fabio the link you provided in comment 74 is not longer valid. Can you please 
provide a new one in order to download the apk? Thanks a lot in advance.

Original comment by alex.zam...@gmail.com on 25 Jan 2012 at 4:17

[GoogleCodeExporter]

Can you explain how that option works? I tried to insert my VPN IP, but this 
did not work, on  asterisk the IP  that appears is always that of 3g or wifi 
connection

Original comment by alien...@gmail.com on 3 Feb 2012 at 3:19

[GoogleCodeExporter]

Hi

You need to give a bit more information about your setup to figure out
what your problem is. The IP you put into "Bind address" and or
"Public address" is the IP of your tun/tap interface on the phone.
This forces the SIP stack to use that interface, so the source address
in the IP headers should be that IP, and hopefully the "contact" IP in
the SIP headers will also contain that IP. If that's what you're
doing, and it's not working, you will probably need to have a look at
the SIP packets with wireshark to see what's going on. If the IP
headers contain the right source address, but in the SIP packets the
"contact" ip is wrong, you might have to use the "force contact" field
as well. Since I added the "Bind address" and "Public address" fields,
I have not had to use "force contact" - for me, it always comes out
with the right IP on it's own - no guarantee that that happens always
though.

Also, I have not tried any recent nightlies that have incorporated my
patch, I'm still using the original APK I made when I first added
those features. Somewhere further up this bug thread, I posted a link
to that APK - as a last resort, try to use that version and see if it
works.

Andrew

Original comment by andrew.h...@gmail.com on 3 Feb 2012 at 8:57

[GoogleCodeExporter]

Hallo,

I have the same problem. I use OpenVPN and csipsimple always uses the wrong IP 
adress. I currently use the nightly-build from 14. January. Before I tried the 
latest nightly build, but it also didn't work.
My mobile phone has on the vpn the ip 192.168.177.110. My sip-server has adress 
192.168.178.1. A route is set up (I can ping the mobile device via the .110 
adress from my home network), I am very expirienced with OpenVPN so there is no 
mistake.
I set up this 192.168.177.110 adress the two options "RTP bound address". But 
it still doesn't work. Then I set up "RTP port" to 39999 and under "force 
contact rewrite" I had the contact plus this port, but then my SIP server tells 
me that it couldn't establish a connection on that port. I also tried another 
port, didn't work, too.
Wireshark tells me taht csipsimple still tries to go via the adress from the 
wrong network interface. 
Wireshark log:

Via: SIP/2.0/UDP 10.175.17.218:60236;rport;branch=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Max-Forwards: 70
From: "622" <sip:622@192.168.178.1>;tag=xxxxxxxxxxxxxxxx
To: "622" <sip:622@192.168.178.1>
Contact: "622" <sip:622@10.175.17.218:60236;ob>

So obiously in the Via and Contact Headers is the wrong IP. 

Would be great if you can fix this, than csipsimple is the first good VOIP 
client that works correctly (sipdroid doesn't support ilbc so that isn't a good 
VOIP client to me). If you need forther information, please don't hesitate to 
ask.

Thanks for your help.

Original comment by b6140...@nwldx.com on 4 Feb 2012 at 3:49

[GoogleCodeExporter]

If you try to connect without the VPN connection setup, do you get
"Failed to create transport Cannot assign requested address" and
"Failed to create media transport Cannot assign requested address"? If
not, then it's not doing what I intended it to do, and maybe the patch
got changed somehow in the latest nightlies. Also, the settings
involved (at least in my version - maybe not in the nightlies) are
under account settings (have to be in expert mode) Bind Address and
Public Address. Do not force contact rewrite, and do not set the "RTP
Bound address" - I'm not even sure where that setting is, unless the
text got changed for my setting names.

Can you try my version of the apk? It's here (just the same as in
comment 70 in the bug thread)

http://www.ece.ualberta.ca/~hakman/CSipSimple/

That version works perfectly for me, and is my original changes, so if
that works, and the nightlies do not, then that's something you need
to report back to the bug, so that it can be fixed.

Andrew

Original comment by andrew.h...@gmail.com on 5 Feb 2012 at 10:55

[GoogleCodeExporter]

In nightlies it's also in expert wizard mode. It's almost same changes than 
yours Andrew. The biggest difference is that it's now based on pjsip-2.x so I 
didn't applied it strictly, but the idea is the same. 
I also added some new options about QoS and all changes of pjsip-2.x as account 
options.

Also as far as I understood, pjsip-2.x now start the media transport only when 
it's needed (just before the call is established).

Original comment by r3gis...@gmail.com on 5 Feb 2012 at 11:00

[GoogleCodeExporter]

I will give the latest nightlies a short sometime when I have time to
muck around, and see if they work for me. Perhaps later today, but
possibly not too!

Andrew

Original comment by andrew.h...@gmail.com on 5 Feb 2012 at 11:06

[GoogleCodeExporter]

With the latest nightly, there is no option "Bind Address" and "Public Adress". 
Neither in Account-Settings nor in expert sip account settings (also tried with 
trunk 1247). There are only those to "RTP Bound Address" options.

@Andrew: I've tried your version already before, but it didn't work. I left 
public adress empty, because a) I only have one 10.x.x.x adress and b) this 
changes very often, so I can't specify this one. I've only setup "bind address" 
and there I set up 192.168.178.110, but it also registers with the 10.x.x.x 
address. I tried your version now again, but it is same negative result.
Routing from the mobile phone seems to be correct, because there is a 
datastream from csipsimple to 192.168.178.1 of about 4 KB/s (ilbc-Codec), so 
that works.
But because it registers with the 10.x.x.x adress and so no audio comes back 
from the sip server.

If I open CSipSimple without established OpenVPN-Tunnel it just can't register, 
there's a timeout, but thats obvious because 192.168.178.1 can't be reached.
If I register and then cut the VPN it tries to establish the call as before, 
but after ~30 seconds it gives up and ends the "call" (andrew's version). r1247 
nightly tells me after a few seconds that connection has been lost and handover 
is not yet supportet and call screen stays.

Forgot to mention in my post from the 4. february, that CSipSimple works when I 
route the whole traffic through the VPN, so sip account data, codecs and so on 
are correct. But routing the whole traffic is no option for me. In German 
IP-Phone-Forum there is another user with the same problem and routing the 
whole traffic through the VPN also works with that user.

Hope you can fix this very soon.

Original comment by b6140...@nwldx.com on 7 Feb 2012 at 10:02

[GoogleCodeExporter]

The name is just different but it's RTP Bound address ;).

In fact there is several different point. I think that what we could advise for 
the first setup is to have address set by a DHCP that always assign same IP 
address to same device (based on mac address). At least for the first step it 
will help a lot.

Then there is several things to check.

The first thing is the contact used to register. Usually this is not so 
important if the "contact" field is not properly registered because the socket 
between sip server and csipsimple should not be cut. So the server will always 
be able to announce an incoming call. It can become more annoying when 
announcing the ip of the device to the remote party and can lead the remote 
party to be unable to send the ack. In this case, your will observe an 
established call that never gets confirmed (and the app will end the call about 
30s later).

To fix this part, it's about fixing the "contact" field. There is several 
things to check/try to configure properly. The first thing that could definetly 
solve the problem is to have a STUN server on the LAN of your sip server. This 
is the best and faster solution. The application will ask your stun server for 
it's "public" ip. And your stun server will reply from the LAN point of view 
what is your public IP. It will also help for the media part.
http://sourceforge.net/projects/stun/
It's pretty easy to install. That's what I use when I've a NATed LAN topology. 
(We can consider the VPN as a NATed subnetwork of your LAN).
In this case, you only need to configure the stun server. Then bad side is that 
for now pjsip does not support per account STUN server. So it force you to have 
your stun server dns resolved both on public and private. But that's something 
that can be done if you have a complete control on your network and SIP server. 

If you are not able to install a stun server somewhere on your sip server lan. 
You'll have to understand how settings works for contact field in csipsimple.
The first thing to know is that there is a "force contact" field that may allow 
to force what is announced by csipsimple to be the contact sip uri (with the ip 
of the device). Obviously in this case you have to know what will be the public 
ip of the device. So I do not advise to use this way.
Then the app is able to auto detect the ip.
This first thing it does, it's binding your server. Thanks to the fact the 
socket will be bound to the server using linux socket layer, it will be able to 
retrieve the address of the interface used (local ip address) to bind the 
server. It's the address of the local interface that bind the sip server. It 
will first register with this address.
Then, if you activated the option "Allow contact rewrite" it will look at the 
reply of the register from the server. The sip server can inform about the sip 
address it can see from its point of view. When "allow contact rewrite" is 
enabled, the application will then take into account this information and send 
a new registration (with an inline unregister -- you can use legacy unregister 
if sip server does not support that). In case of sip server that manage sbc, it 
can lead to mess up the sip server and this option has to be disabled. In other 
cases it can helps to register with the correct ip address.
Also, once pjsip get this ip, it consider it as the public ip.

That's for the "Contact" header field.

With that done and properly registered on your server, you'll have to check now 
the media ip. The one that will be used to establish media path between the two 
clients.
In this case, stun can also help. 

Here comes the RTP public address (there is a name problem in the nightly I've 
just fixed it ;) -- but it's the first one) and the RTP bound address.
The RTP public address is the address that will be sent in the SDP by the 
application to announce the remote party where to send media. Obviously it 
needs the device IP and port mapping to be fixed. This one is about the 
announce that is done to remote party. Normally it's autodetected by the 
application, but again in some network topology there is no ways to find it 
out. (and again, stun is a good solution for finding that out).
The RTP bound address is the ip address of the local interface you want to 
force the app to use for media. 
About these two options, you can have a look here : 
http://www.pjsip.org/docs/2.0-alpha2/pjsip/docs/html/structpjsua__transport__con
fig.htm

I hope that these explaination enlights a little bit things. Normally in your 
case, it's really about configuration. SIP protocol is not really done for 
NATed network when used alone. To solve this problem they introduced STUN (and 
many other techniques). It's always very tricky to configure and really depends 
on sip server and topology. The behavior of csipsimple is very configurable due 
to the fact I try to give access to all field of the sip stack so that you 
should be able to configure it for your needs provided the fact it's 
technically possible to do so.
I mean, if the sip stack is never able to get the media ip/port it will never 
be able to send a correct information to the remote part and media path will be 
wrong.

I repeat myself, but in your case, I think that it's more about a NAT problem 
than about the fact it's VPN. I think that with a wifi hotspot that create a 
NAT network under your LAN, you'll get exactly the same problem. So you should 
consider solve the NAT issue first before thinking about VPN stuff. And the 
easiest way is to have your own STUN server as you have your own SIP server.

Original comment by r3gis...@gmail.com on 7 Feb 2012 at 10:40

[GoogleCodeExporter]

seeing as you're playing around with vpns and advanced sip stuff, I'm
assuming it would be no problem for you to give the output of

busybox ifconfig

when your vpn is connected?

I'm not clear whether your vpn is routed or bridged as well - that
would also be useful to know.

Andrew

Original comment by andrew.h...@gmail.com on 7 Feb 2012 at 12:44

[GoogleCodeExporter]

also, ifconfig output of your openvpn server, and your asterisk box
would also be useful. Obfuscate any public ip's if you're worried
about that - all that's really important is the vpn and private
networks.

Andrew

Original comment by andrew.h...@gmail.com on 7 Feb 2012 at 12:48

[GoogleCodeExporter]

The whole point of the VPN is it takes NAT out of the equation. With a
VPN, you should have only 2 networks that you care about, and both use
normal routing (or switching, in the case of a bridged vpn) to pass
traffic between them, not NAT. There should be a) the network the sip
server resides on (typically private, but it doesn't make any
difference as long as the VPN server knows how to contact it), and b)
the VPN network (which is almost always private, but again, not really
important).

If setup correctly, all machines on either of those 2 networks can
ping machines on the other one, and there is no NAT involved, just
simple routing. No truly "public" IPs should be involved anywhere,
just the IP of the VPN client, and the IP of the SIP server. All the
NAT nastyness is hidden behind the VPN connection, which only uses one
port, and thus is easy to get through NAT, or almost any other kind of
stupidity one encounters at random public internet connections.

Because of this, I don't think the issue is NAT based, but rather
something to do with how the ip addressing of the internal vs vpn
network is setup, or incorrect subnet masks, or something similar,
which is why I'd like to see how the interfaces are configured on the
various machines.

To that end, the output of

route -n (or busybox route -n possibly on the phone - I don't remember
whether the native Android one works properly or not - I know the
native ifconfig on Android prints nothing, and you need to use the
busybox version to actually see what's important)

on the various boxes would also be quite useful

Andrew

Original comment by andrew.h...@gmail.com on 7 Feb 2012 at 1:05

[GoogleCodeExporter]

Thanks for your detailed reply. You're posting faster than I can analyse and 
write :).
I think there is some misunterstanding with NAT, so I'll try to explain.
I have a 2 Point VPN and my mobile phone always gets 192.168.177.110. This 
Adress is directly routet to my home network (192.168.178.0/24) without any NAT 
in between. Its routed to have less overhead, not bridged.
The 10.x.x.x private adress is from my provider and their DHCP. They perform 
NAT for my Internet Connection. On that 10.x.x.x interface there has to be only 
the VPN data and no data from CSipSimple (except encapsulated in the VPN of 
course).  So I think a STUN-Server in my network would not really help. 
My SIP server is a AVM Fritzbox and there I see detailed Internet-Call Log 
settings. There is the 10.x.x.x IP where it tries to send the RTP datastream. 
I use the same setup with x-lite softphone from my notebook and the same VPN 
Tunnel (then it is deactivated on the mobile phone) and everything is fine. 
Even the internet comes via Tethering from my mobilephone. It also works with 
Sipdroid on the mobile phone (but then only in HSDPA networks because of the 
lack of ilbc). So I doubt that it is a NAT problem. The only difference between 
the two OpenVPN configs is one line "redirect-gateway def1" than it works.

I've already tried the force contact field header with IP adress 
192.168.177.110. Then my fritzbox tried to connect to that IP, but now the port 
is the problem. I tried 39999 and set this as "RTP Port" but then my fritzbox 
showed in the log that it couldn't connect to port 39999. I've also tested 
another Port with the same negative result.

CSipSimple sends the data out on the right interface, otherwise their wouldn't 
be ~3-4 KB/s traffic on the VPN, but no data comes back, there isn't even a 
dialtone, which comes when I redirect all traffic through my home lan (see 
above).

"Then, if you activated the option "Allow contact rewrite" it will look at the 
reply of the register from the server. The sip server can inform about the sip 
address it can see from its point of view. When "allow contact rewrite" is 
enabled, the application will then take into account this information and send 
a new registration (with an inline unregister -- you can use legacy unregister 
if sip server does not support that). In case of sip server that manage sbc, it 
can lead to mess up the sip server and this option has to be disabled. In other 
cases it can helps to register with the correct ip address."

That sounds interessting and I verified it. When I have disabled "Allow Contact 
Rewrite" then csipsimple registers only with my 10.x.x.x adress. When I enable 
it csipsimple reregisters with the correct 192.168.177.110 adress. I have to 
use the legacy unregister, otherwise I have "2 bindings". However I often get 
an error "Bad request" I have to reregister, than it works, but thats not so 
important.

However I now found the problem. I focused to much on the SIP register part 
only. SIP always worked, meaning that incoming calls were always displayed at 
my mobile phone, so the correct IP-adress had to be in the contact field that 
it worked.

I examined the SIP invite packet and there is the problem. In the SDP header 
there is 
"Owner/Creator, Session Id (o): - 3537609596 3537609596 IN IP4 10.170.62.128
Session Name (s): pjmedia
Connection Information (c): IN IP4 10.170.62.128"

then a few lines below
"Connection Information (c): IN IP4 10.170.62.128
Media Attribute (a): rtcp:40001 IN IP4 10.170.62.128"

So there is the problem. When I use "redirect-gateway" then there is the 
correct 192.168.177.110 address in this fields and then calls work. 
No we are on the right way to solve that problem.

If you still need some outputs from my various device, please tell and I'll 
give you. I have fritzbox, VPN-Server (with IP Routing between Fritzbox and 
mobile phone) and my mobile Phone. But I'm sure that there is no 
misconfiguration with routing because I'm using OpenVPN for years now.

BTW: I noticed, that CSipSimple does not display SIP error codes, espically 
"busy here" is not shown, instead the call is just ended. Please fix that, too.

Original comment by b6140...@nwldx.com on 7 Feb 2012 at 1:42

[GoogleCodeExporter]

Well, it really depends on your VPN configuration. On comment #85 and #81 I see 
that b6140296 use 2 differents network address plan (192.168.x.x and 10.x.x.x). 
I use to see this kind of configuration when there is some NAT on the middle 
(usually on the VPN server). And also it's the default behavior if the route to 
the VPN subnetwork is not set on gateway of the sip server network.
-- Also, what is important in this case is that the sip server can route to the 
sip client --

But you're right, it could be a little bit fast assumption. However, it could 
also explain why it does not work with your version either ;). So for b6140296 
I think that it would be a good idea to check that first. 
In case of a routing/switching configuration sip client must be able to ping 
sip server (usually obvious) but also sip server must be able to ping sip 
client (less obvious).

But indeed, if that's a simple routed network as in your case, NAT stuff are 
not relevant.

And as I said at the very begin, normally VPN should not really be a problem 
from pjsip point of view. But possibly android (or alternative ROM) mess up 
things in the middle so that the linux native socket layer is lost trying to 
open sockets. So the workaround to force using an interface is needed.
I think that it's not required on all ROM, because on my device it worked 
flawlessly (no config needed at all) with a VPN lab I made at home. The hardest 
thing to do was to configure the network topology properly.

Original comment by r3gis...@gmail.com on 7 Feb 2012 at 2:00

[GoogleCodeExporter]

Oups, didn't see your comment before posting :)
Ok so I misunderstood your problem.

Original comment by r3gis...@gmail.com on 7 Feb 2012 at 2:03

[GoogleCodeExporter]

Well sounds you find the reason :)

Sounds it's the same problem than Andrew finally. It's about the RTP bound 
address/port.
By default pjsip will bind 0.0.0.0 and listen everywhere. 
To announce in the SDP pjsip use the default gateway to choose the highest 
score interface. In your case if "redirect-gateway" is not enabled, the stack 
will consider that a remote party is more likely to use the interface that has 
gateway. And so will announce with 10.x.x.x in your case.

In order to solve that : the RTP bound address. It will force the RTP transport 
to bind only the interface you specify and so, it will announce the correct one 
in SDP :) (it should ;) ).

So, even in this case, STUN could be useful. Normally media plan and control 
plan are not linked in SIP. 
Pjsip guys try to respect that I think. That's why the RTP address is not 
linked to the SIP address. Sipdroid does a lot of crappy things. Maybe 
pragmatic... but that are not necessarily in line with SIP RFC. You could have 
a look to the issue about pbxes.org (the company behind sipdroid) and TCP. They 
have a very pragmatic approach (also very pragmatic for their service ;) ), so 
sometimes it can lead to have something working easier. 

Also, side note, even in this case, a STUN server could help. As it will inform 
pjsip of the ip/port seen from the sip server it may be very useful (even if no 
NAT ;) ).
Since STUN is common to control and media plan it can be used by the stack to 
find out the ip/port independantly and cleanly without making any assumption on 
the fact control plan and media plan must use the same path.

Original comment by r3gis...@gmail.com on 7 Feb 2012 at 2:23

[GoogleCodeExporter]

Last point about the topic, one related issue in pjsip project : 
https://trac.pjsip.org/repos/ticket/11

Even if probably a good solution on android would be to configure the account 
on the fly using a plugin to csipsimple depending on network connectivity 
(because android APIs gives more infos).

Original comment by r3gis...@gmail.com on 7 Feb 2012 at 2:30

[GoogleCodeExporter]

When it is the same problem than Andrew, I wonder why his version does not work 
with me. I use Android 2.3.6 (since today) and before I tried with Android 
2.3.4. 

RTP bound adress does not work for me, sadly. The question is why. Perhaps I 
configuread it wrong. In the field RTP bound adress (both), I set 
"192.168.177.110", without the quotation marks, of course.  

I'd like to avoid a stun server, I prefer using the RTP-bound adress. Since my 
VPN adress stays the same, that should be no problem. 
Next question is why does X-Lite work on the laptop, there is a similar 
situation.

Original comment by b6140...@nwldx.com on 7 Feb 2012 at 2:59

[GoogleCodeExporter]

I really don't know why my APK wouldn't work for you, because that's
the same issue I had initially. CSipsimple (or rather pjsip in the
background) kept binding to the wrong interface, so I added the fields
to be able to force it to bind to the VPN interface.

It's strange though that when you use my apk, you don't see the error
messages popping up I do if the VPN interface just ins't up. It should
definitely be throwing up an error about "cannot bind to interface -
doesn't exist" (or whatever the exact text was I mentioned initially).
 Do you possibly have more than CSipSimple installed at once somehow?
I don't think that should be possible, but I can't see how it can do
what it's doing for you, unless the wrong code is being executed
somehow.

The "rating" algorithm that pjsip uses to pick which interface to bind
to is just really wrong. From what I can tell, it almost always picks
the default gw, even if there's a better match (IP wise) available.
But yet in some cases it seems to work, and others, it just doesn't at
all. I have a feeling in the cases where it "works" and people are
using VPNs, it really isn't using the VPN at all, but things are
managing to connect because of STUN, or something similar, so it just
works, and people don't notice.

Either that or in some stock Androids, I think the providers have
mucked with the network stuff to try to get you to not be able to
tether the phone for free, or use VPNs over their network or
something. What Android are you running? Stock, or a open source
build, or what? I'm using Cyanogen (mostly because of it's built in
openVPN functionality out of the box - not that compiling that into
any kernel is that hard. Even with Cyanogen, I have an alternate
kernel I compiled for when I need USB host support on the phone).

Andrew

Original comment by andrew.h...@gmail.com on 8 Feb 2012 at 3:48

[GoogleCodeExporter]

Just for info, I'm using Android 2.3.3 with kernel
2.6.37.4-cyanogenmod-82245-g7f230e8

Original comment by andrew.h...@gmail.com on 8 Feb 2012 at 3:57

[GoogleCodeExporter]

I have Counterpath Bria also installed, but it was not running when CSIPSimple 
was running.
I have now setup the Stun-Server from Sourceforge (link some posts above) and 
now everything works. Thank you. I thought that would be more difficult. 
However I don't understand why the Stun-Server insists on 2 network-interfaces 
and with binding to 0.0.0.0 it really won't work, you have to specify the IP of 
your interface you want it to bind. You can specify only the IP-adress of your 
interface and everything works, eventhough the Stun-Server tells you Stun won't 
work because you haven't specified a second IP. 

I'm using this 
http://www.android-hilfe.de/original-firmwares-fuer-samsung-galaxy-s/188200-firm
ware-2-3-6-29-12-2011-i9000xxjvu-value-pack-odin-root.html version.
You don't have to build your own tun.ko module or kernel. I just use this one 
http://forum.xda-developers.com/showthread.php?t=793712 and everything is fine. 
It worked with 2.3.4 and now with 2.3.6. I also have another tun.ko (don't know 
anymore where I got that from) but that also worked with 2.3.4, didn't test it 
yet with 2.3.6. So it is not necessary to build your own tun.ko.

BTW: I've also tried Cyanogen, but I didn't like the userinterface.

Original comment by b6140...@nwldx.com on 8 Feb 2012 at 7:48

[GoogleCodeExporter]

@b6140296 : About stun server, I was also a little bit surprised that it 
requires two interface. One works pretty well. I think that there is some parts 
of the STUN specification that can't be implemented with only one interface, 
but as far as I can tell having only one is enough for simple needs.

@andrew : I think that's a complicate debate to say what should be the good 
interface to choose.
I think that one important point is to ensure that the app consider media and 
control network plan as independent plans. 
For example, you can consider a network topology where you have
Client 1 <Network1>-----<>Server
Client 2 <Network1>-----<>Server
And for the voice path
Client 1 <Network2>-----<Network2> Client 2
This topology should not be avoided in SIP protocol. SDP is about negotiating 
media and from an abstract point of view it should not take into account the 
control plan.

Then, all is about how the sip stack decide which interface it chooses to 
announce. I agree with you that the way it's chosen by pjsip is maybe not the 
best way from a pragmatic point of view in our case.
As far as I understood this rule : 
http://trac.pjsip.org/repos/wiki/FAQ#multihomed applies. So indeed, it's more 
likely to choose the interface on which there is the gateway with this 
algorithm . 
Also, I think that I didn't reproduce the issue because on my VPN lab I use the 
VPN to get out : all traffic was going out through the VPN. There is as many 
VPN topology as simple private network topology ;).

Then about how legitimate this algorithm is, I reasonably can't judge. I'm far 
to be a SIP expert -I leave all that stuff to pjsip guys-;
In this specific case, their algorithm is not a good idea. But we can't exclude 
that there is other cases where it's not a good idea to announce in SDP the 
interface used for control plan. 
At least, doing this the way pjsip does is not something wrong regarding SIP 
RFC - from my understood-. 
Besides, something to be aware of is that pjsip stack is not a monolithic sip 
stack. It's modular with different parts and the one responsible of media 
negotiation is different from the one in charge of call control. 
It allows projects (such as blink and sflphone if I don't mistake) to use a 
different media stack with more features (desktop sharing).

Maybe pjsip guys could provide more information about this choose and an option 
to use the same interface than the one used for control plan would be a good 
idea. I'll do some investigation in pjsip source code to see if there is 
something simple for that. 
And then ask on pjsip mailing list. 

If you want to get more info or ask directly pjsip developers, you can directly 
ask them here :
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

Maybe you will have better arguments than me and will explain it better ;) - as 
you probably notice, English is not my native tongue ;)

Original comment by r3gis...@gmail.com on 9 Feb 2012 at 10:43

[GoogleCodeExporter]

Hi,

i haven't read this thread for a while.
During a web server upgrade i forgot to upload my patches on the new server.
Here are my patches and the apk again.
http://lombardi.mobi/csipsimple/

Be advised, this apk is based on trunk of september.

Original comment by lombi...@googlemail.com on 13 Feb 2012 at 10:50