#2497 Seems not to work with two network interface / OpenVPN

[Anonymous]

Originally created by: lorta...@googlemail.com

I have set up an OpenVPN tunnel to the network where my SIP-Gateway is located in. When I start csipsimple the registration works well. But no call is working. So I take a look into the network traffic. And indeed csipsimple mixes up the IP addresses. During the registration it works with the IP address assigned to OpenVPN interface. During the call, the UDP packages from csipsimple have the IP address assigned to OpenVPN interface as source address.

BUT the SIP-Gateway send its UDP packages to the IP address assigned to the WLAN interfaces of the devices where csipsimple is running on.

Of course, these packages will never reach csipsimple.

I took a look into the configuration, but did not find any setting how to change this behaviour. And being honest, there is no need for a setting:

During the registration csipsimple should tell the SIP-gateway to send its packages to the IP address, which is used for sending packages to the SIP-gateway. (Outgoing IP address should always be the destination IP address for the other side. Except in case of NAT, of course :) )

[Anonymous]

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

If I may add a little more detail to this problem.

Using a Samsung Galaxy S4, connected to another network using OpenVPN, where an asterisk server resides.

10.17.6.138 is the OpenVPN tun interface IP.
10.17.2.6 is the asterisk server.
192.168.70.28 is the wifi IP address on the Galaxy S4

Although the application correctly uses the tun interface IP address for SIP communication, it incorrectly inserts the wifi IP address into the SDP as show below.

Great app otherwise by the way :o)

20:30:54.019102 IP 10.17.6.138.34670 > 10.17.2.6.5060: SIP, length: 975
E.....@.@..C
...
....n....=.INVITE sip:3099@10.17.2.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.70.28:34670;rport;branch=z9hG4bKPjd2hZn8iujLJpdF5V.trQtiuWt1GlmTSp
Max-Forwards: 70
From: "George" <sip:george@10.17.2.6>;tag=Cn.89ULTV71sRocuWnf-k9ikglu04GCq
To: <sip:3099@10.17.2.6>
Contact: "George" <sip:george@10.17.6.138:34670;ob>
Call-ID: YqniRM5kVe0tLAYDA32dt5nwuGbyvzPw
CSeq: 8514 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: CSipSimple_jflte-17/[r2330]
Content-Type: application/sdp
Content-Length:   344

v=0
o=- 3593190651 3593190651 IN IP4 192.168.70.28
s=pjmedia
c=IN IP4 192.168.70.28
t=0 0
m=audio 4006 RTP/AVP 99 0 8 101
c=IN IP4 192.168.70.28
a=rtcp:4007 IN IP4 192.168.70.28
a=sendrecv
a=rtpmap:99 SILK/24000
a=fmtp:99 useinbandfec=0
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

[Anonymous]

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

What you see is absolutely expected and normal.

You can read my comment on issue 2375.
There were also a long thread on issue 390 that you might be interested to read.

In short solutions are (from best to worse) :
- Use ICE and have all your nodes supporting ICE
- Use a STUN server on your VPN-LAN
- Fixes ip address and use the RTP announce address option in expert account settings mode.

Mergedinto: 2375
Status: Duplicate