#2655 Uses wrong IP address in Via/Contact headers when on OpenVPN

[Anonymous]

Originally created by: _...@maxb.eu

What steps will reproduce the problem?
1. Install "OpenVPN for Android" from Play Store
2. Connect to an OpenVPN server
3. Attempt to REGISTER with a SIP server over the VPN

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

SIP messages sent over the VPN should have the phone's VPN IP in the Via and Contact headers. Instead they have the phone's underlying wifi IP in the Via and Contact headers. So no SIP responses reach the phone.

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

Nexus 5
Android 4.4.2
csipsimple 1.02.00 [r2330]

[Anonymous]

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

I'm not sure to get the details of the problem but it can be a normal behavior. I did a lot of tests with VPN on the device, and everything I observed was expected. It's often not obvious to understand but it's always strict regarding RFC.
So can you collect and send logs. See HowToCollectLogs wiki page (ref this issue number in the email produced).

The fact that some interface is used to reach a server does not means it also should be used for media for example.
The "allow contact rewrite" option that is enabled by default should do the trick so that the registration will be finally made with the correct ip address (after the first step).
For the media, if the default interface is not the vpn interface in your topology, the good way to configure the app is to enable ICE.

Because else, there is absolutely no good reason to use the vpn interface. To support all possible topologies things needs to be clear and not magic should happen else we will loose support of some topology (it's totally possible to have invite going through your sip server in the vpn network but media established over public network).

Status: Need-Details

[Anonymous]

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

Yes, this bug is present. I have Asterisk server in freeBSD Jail and OpenVPN tunnel. I can "see" clients from jail box and via versa. Problem in csipsimple.

Look at this log

IP 192.168.254.130.40671 > 192.168.254.10.5060: UDP, length 834
E..^..@.@..........
.....J. INVITE sip:5433@192.168.254.10 SIP/2.0
v: SIP/2.0/UDP 192.168.1.134:40671;rport;branch=z9hG4bKPjMEB0vxQe7jfxIZjwS902SI28SLUvnVW3
Max-Forwards: 70
f: <sip:1111@192.168.254.10>;tag=WFf6MI2aLQJa5aJL295WTw23ywZa.2Vo
t: <sip:5433@192.168.254.10>
m: <sip:1111@192.168.254.130:40671;ob>
i: TOvZBIOxUAokCoOBHFouCSgh5Bdd7nbS
CSeq: 21835 INVITE
Route: <sip:192.168.254.10;transport=udp;lr>
k: replaces, 100rel, timer, norefersub
x: 1800
Min-SE: 90
User-Agent: CSipSimple_bird77_a_cu_ics2-15/[r2457]
c: application/sdp
l:   302

Here 192.168.254.10 - Asterisk's IP-address
192.168.254.130 - client's tunnel endpoint
192.168.1.134 - WI-FI address

I think it must be fixed.

[Anonymous]

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

As workaround you should use "nat = comedia" in sip.conf

[Anonymous]

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

@ffaxinn : I don't think it's a bug in csipsimple.
It's pretty long to explain and I did it a couple of times (read for example : https://code.google.com/p/csipsimple/issues/detail?id=2375#c2)

To try to be very short to explain why it behaves this way :
In SIP, media and control plan are distinct. There is absolutely nothing that force your media to go the same way your sip control.
And it makes sense it some cases !!!
SIP allows for example your call to be created using your sip server in your VPN but media to go directly in the shortest possible way over the internet using for example totally encrypted peer to peer method.

Now your case. Apparently, you would like your media to go the same network your sip does. Unfortunately your log does not show the part about media, so I can just guess that's your case, which is the same than many other people ;). And I guess from your solution than problem was about media.

Fine, that's possible, but that will require you to learn a little more about SIP vs networking :)
There is one very simple way to do thanks to recent addition in pjsip (the underlying sip stack behind csipsimple). In expert account mode (https://code.google.com/p/csipsimple/wiki/ExpertSettingMode?wl=en#Account_settings), you can check the Allow SDP NAT rewrite option (in nat traversal section).
This way, the app will not assume it should announce media on the default route interface of your device, but instead try to use the one that was used to reach your sip server.

A second solution, which I advise to consider for all providing a SIP server and with a complex network topology (several network/VPN etc etc), is to setup a STUN server on your sip server and enable STUN+ICE in the app.
This way, the app will ask stun server what should be it's media public IP to stun server(s) (thx to STUN); and announce to remote all possible media public IP (thanks to ICE, which allows to announce all interface + all ip resolved by all stun servers).

That's why it's not a bug, but something in the configuration that does not match the topology you'd like to achieve. SIP can become complicate to configure depending on topology. The next gen com stuff uses by default methods such as STUN+ICE (it's the case of webRTC), or uses very restricted scenarios available.
The point about nat media is not the only one that can be configured and that you might have to configure to get something working when you are providing a SIP server. There is no magic config that works for anyone because there is many possible configuration for network+SIP. However, the expert setting mode of csipsimple should allow to tune every single thing on how SIP stack behaves. That's basically why there is this "wizard" approach with predefined settings depending on sip provider. And you can check in the code, many sip provider has their own different settings to get sip working properly even if they almost always have only to manage public connection.