#2375 UDP Bind Address not correct when using VPN with fritzbox

[Anonymous]

Originally created by: mast...@gmail.com

What steps will reproduce the problem?
1. Install VPNcilla, and connect to your FritzBox VPN in a way that only packets for 192.168.1.0/24 get routed trough the VPN Tunnel.

I used a VPN which tunnels everything, but I can override the settings in VPNcilla.
I used VPN in a fast UMTS Network which allows VPN.
I also tested the VPN in a friend's WLAN
The VPN Tunnel works fine

2. Install csipsimple, register the Fritz Box telephone account as a basic profile in csipsimple
(fritz box IP, user "name" and password)

3. Make a Phone call, you can only hear the other person talking, but the other person cant hear you

4. Convert the basic profile in a expert profile, change the UDP bind address to the address you get from the VPN Tunnel (192.168.1.201)

5. Make a call, everything works finde

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

That you don't need to force the UDP bind address, because I use the same Account in my Fritz Box WLAN.

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

Android 4.2.2, recent versions of VPNcilla and csipsimple from the Play Store.

Please provide any additional information below.

There is a VPNcilla trial app for testing.

Contact me if there are more questions

[Anonymous]

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

This also happen with OpenVPN and Android bundled VPN profiles.

[Anonymous]

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

What you observe is expected.
It's linked to how pjsip (the sip stack that csipsimple uses) resolve your public ip:port to publish.

I'll explain you how it works currently and you'll understand why it publish this ip:port.

- First thing to know is that in SIP control plan (SIP) and media plan (RTP) are different. The route used for control is not necessarily equal to the route used for media.
- The sip stack when you send the sdp needs to announce some ip:port to reach it.
    * if stun is enabled : the stack will ask the stun server what is it's public ip:port for the media layer. This will resolve the exact ip:port as seen by the stun server and is very reliable if the stun server is in the same "network" than your remote part. In your case, if you have a stun server on the same network than your vpn lan, it will resolve with the ip you expect.
    * if ice is enabled : the stack will resolve all possible public ip (all interface of the phone + ask all stun servers) and will give in the sdp as ice candidates all possible IP. It requires the remote part to support ICE. This is the very most reliable way. In your case if ICE is enabled and supported by remote part one of the candidate is the IP you expect.
    * if no stun and no ice, then the app have few clues to know which is the good ip:port to send. The current default approach of pjsip in this case is to find the ip:port that is more likely to be reachable from outside. And it's considered that it's the interface where you default gateway is configured. Apparently in your case the default gateway is not the vpn, so it's not the one chosen. But it's still a valid IP.
- Now, lets consider the topology : you reach your local sip proxy on your LAN that forward the request to another sip server/client on the public wan. If your sip server is not a media proxy and if the remote cannot reach your LAN, the best way to reach you is to use directly WAN and your public IP address (instead of the VPN one). In this case, what's sent by default by pjsip as RTP ip is needed.
As there is no clue on the topology in this situation, the decision on which RTP public IP to use is someone by definition not sure decision because all IP could be valid. BTW, that's the purpose of ICE (sending possibles candidates because the sip client is not sure where is the remote part and how it could reach us).

So, that's just about topology and configuration. And that's not a bug but due to the strategy the media ip is resolved when nothing for multihomed SIP (ice) is used.
However, good news for your very special topology (without stun/ice and with vpn that is not default gateway), pjsip guys introduced very recently an option to use the IP address found during registration process (so from the sip control plane) as the address for SDP (RTP media plane). I didn't had time to introduce the option in csipsimple expert settings yet but I'll try to do that very soon.
For reference the ticket on pjsip side : http://trac.pjsip.org/repos/ticket/1668

Status: WrongConfig

[Anonymous]

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

Issue 2315 has been merged into this issue.

[Anonymous]

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

Issue 2434 has been merged into this issue.

[Anonymous]

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

Unfortunately it doesn't help - I still have WiFi IP address as RTP outbound IP address

[Anonymous]

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

Issue 2497 has been merged into this issue.

[Anonymous]

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

Just to make sure you know - I've installed the latest [r2375] and there is no audio. Killed CSS several times, restarted - noting. Primary codec is GSM at this time. "Info" indicates - there is no RX packets, only TX. I've returned back to [r2373] and everything is OK now.

[Anonymous]

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

No I didn't knew that. Thanks for reporting.
Only changes made between [r2373] and 2375 should be about opus codec. 2373 itself has a big change in it however.

So are you sure 2373 is ok?
I'll check on my side if opus changes could break something (it's still possible as something inside stream management has been changed but should only run when codec is opus).

[Anonymous]

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

Ok, I found the problem in opus changes. Indeed, it breaks all other codecs ... I'll fix that right now and produce a new nightly build as it's critical point. Thanks again for reporting the problem

[Anonymous]

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

I am having this same issue. I would love a solution to using csipsimple over VPN. I am trying to use the RTP public IP and the RTP bind options in expert mode, but it still is not working. the wrong IP is always sent to the PBX inside the SIP message.

[Anonymous]

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

Same problem here... I would love a solution to using csipsimple over VPN. [2]

[Anonymous]

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

Weird that using the RTP public IP does not help. Can you send me logs (see : https://code.google.com/p/csipsimple/wiki/HowToCollectLogs?wl=en)
Also, another solution (if remote supports it) is to use ICE.

[Anonymous]

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

Hi guys,

I've installed [r2430]. Where do I find the Option in order to resolve the VPN issue that as deschribed in the first post?

[Anonymous]

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

Hello again,

I found the "Allow SDP NAT rewrite". This definitely delivers die virtual VPN IP to CSipSimple.
BTW, I'm using the same topology as the beginner of this discussion (VPNcilla, and connect to your FritzBox VPN in a way that only packets for 192.168.1.0/24 get routed trough the VPN Tunnel.)

Unfortunately, I still got one problem.

Incoming SIP calls from the FritzBox VPN do not work - there are not even signalized. Switching to complete VPN-Routing solves the issue.
The Android internal sip client displays all incoming calls even in VPN connections that only route FritzBox traffic.

Do you have an idea how to solve this?

[Anonymous]

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

Hello one more time,

could it be that in this particular case CSipSimple does not listen on the VPN IP? Instead in only listens to the actual IP so that it will not recognize incoming calls over VPN.

Best regards
matt

[Anonymous]

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

Alright, now I have discovered the problem:
In incoming call situations the SIP server contacts the client (CSipSimple). The log of my sip server (AVM Fritz!Box) tells me that it is trying to reach the client at its actual IP address (the IP address of the remote network) instead of addressing the VPN IP address.
This is the case even though "Allow SDP NAT rewrite" is activated.

Is there a way to solve this issue.
Otherwise one has to use a VPN mode that tunnels all network traffic of the phone.

[Anonymous]

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

Hi agian,

with Zoiper (an several other SIP apps) everyting works as it is supposed to. So, there is definitely an issue with CSipSimple.