#2315 Cannot make calls over VPN connection

[Anonymous]

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

Using CSipSimple_yecon77_mg789_tb_ics2-15/[r2187]
(and any earlier releases) could not make calls using VPN connection.
I am using it on Android ICS ver. 4.0.4, ZTE e-Learning PAD E7
I have WiFi connection at home, it gives me IP 192.168.5.33 255.255.255.0
I have L2TP/IPSec VPN server at work, after connection it gives me
IP 10.1.3.2 255.255.0.0 (may be changed on next connection)
We have SIP server inside  corporate local network with IP 10.1.7.202 255.255.0.0.
I can successfully login to my SIP account and dial phone numbers.
Called phone acceptes call, but because no data stream establised,
connection is dropped.
As I uderstand, it is because CSipSimple wrongly sets 192.168.5.33 as voice data interface, instead of 10.1.3.2, wich is on same network as SIP server.

Because as I see, no attachments now possible, I will show short part of log file fore one session:

D/libpjsip( 2280): 16:39:08.602   pjsua_core.c !.TX 1051 bytes Request msg INVITE/cseq=29000 (tdta0xe6f648) to UDP 10.1.7.202:5060:
D/libpjsip( 2280): INVITE sip:84957833444@10.1.7.202 SIP/2.0
D/libpjsip( 2280): Via: SIP/2.0/UDP 192.168.5.33:55079;rport;branch=z9hG4bKPj61RWIc7ms3oy5wLPmDdXNYVzrB1ywNxi
D/libpjsip( 2280): Max-Forwards: 70
D/libpjsip( 2280): From: <sip:306@10.1.7.202>;tag=C4xpCMKz46AQr6LV3Adlo9vZI8qZbkb0
D/libpjsip( 2280): To: <sip:84957833444@10.1.7.202>
D/libpjsip( 2280): Contact: <sip:306@10.1.3.2:55079;ob>
D/libpjsip( 2280): Call-ID: .rcsFthdp15m6fNBGMp6-dnKnhDtHV68
D/libpjsip( 2280): CSeq: 29000 INVITE
D/libpjsip( 2280): Route: <sip:10.1.7.202;transport=udp;lr>
D/libpjsip( 2280): Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
D/libpjsip( 2280): Supported: replaces, 100rel, timer, norefersub
D/libpjsip( 2280): Session-Expires: 1800
D/libpjsip( 2280): Min-SE: 90
D/libpjsip( 2280): User-Agent: CSipSimple_yecon77_mg789_tb_ics2-15/[r2187]
D/libpjsip( 2280): Content-Type: application/sdp
D/libpjsip( 2280): Content-Length:   364
D/libpjsip( 2280):
D/libpjsip( 2280): v=0
D/libpjsip( 2280): o=- 3574327116 3574327116 IN IP4 192.168.5.33
D/libpjsip( 2280): s=pjmedia
D/libpjsip( 2280): c=IN IP4 192.168.5.33
D/libpjsip( 2280): t=0 0
D/libpjsip( 2280): m=audio 4002 RTP/AVP 8 9 0 3 106 101
D/libpjsip( 2280): c=IN IP4 192.168.5.33
D/libpjsip( 2280): a=rtcp:4003 IN IP4 192.168.5.33
D/libpjsip( 2280): a=sendrecv
D/libpjsip( 2280): a=rtpmap:8 PCMA/8000
D/libpjsip( 2280): a=rtpmap:9 G722/8000
D/libpjsip( 2280): a=rtpmap:0 PCMU/8000
D/libpjsip( 2280): a=rtpmap:3 GSM/8000
D/libpjsip( 2280): a=rtpmap:106 speex/16000
D/libpjsip( 2280): a=rtpmap:101 telephone-event/8000
D/libpjsip( 2280): a=fmtp:101 0-15
D/libpjsip( 2280): --end msg--
D/PowerManagerService(  246): releaseWakeLock flags=0x1 tag=SipWakeLock total_time=15ms
D/IPCThreadState(  246): [DN #5] BR_CLEAR_DEATH_NOTIFICATION_DONE cookie 0x11fe5a8
V/AlarmManager(  246): Checking for alarms... rtc=1365338348621, elapsed=1521856
V/AlarmManager(  246): Checking active alarm when=1521855 Alarm{42068ad0 type 2 com.csipsimple}
V/AlarmManager(  246): Alarm triggering: Alarm{42068ad0 type 2 com.csipsimple}
V/AlarmManager(  246): Checking active alarm when=1524698 Alarm{41f87808 type 2 com.csipsimple}
V/AlarmManager(  246): Native set alarm :Alarm{41f87808 type 2 com.csipsimple}
I/AlarmManager(  246): bootpackage = com.android.settings set Prop 2
I/AlarmManager(  246): rest power off alarm is com.android.settings
D/Provider/Setting(  246): NameValueTable putString power_off_alarm_package_name in content://settings/system value com.android.settings
D/Settings/Provide(  246): isRedundantSetValue, oldValuecom.android.settingsvaluecom.android.settings
D/Settings/Provide(  246): SettingsCache.isRedundantSetValue power_off_alarm_package_name com.android.settings
V/AlarmManager(  246): sending alarm Alarm{42068ad0 type 2 com.csipsimple}
V/ActivityManager(  246): Broadcast: Intent { act=com.csipsimple.PJ_TIMER dat=timer://256 flg=0x14 (has extras) } ordered=true
D/ActivityThread( 2280): BDC-Calling onReceive: intent=Intent { act=com.csipsimple.PJ_TIMER dat=timer://256 flg=0x14 (has extras) }, ordered=true, receiver=com.csipsimple.utils.TimerWrapper@414960c0, IIntentReceiver=41470740
D/PowerManagerService(  246): acquireWakeLock flags=0x1 tag=SipWakeLock
D/ActivityThread( 2280): BDC-Calling finishReceiver: IIntentReceiver=41470740
D/PowerManagerService(  246): acquireWakeLock flags=0x1 tag=AlarmManager
D/PowerManagerService(  246): releaseWakeLock flags=0x1 tag=AlarmManager total_time=0ms
I/libpjsip( 2280): 16:39:08.655 pjsua_jni_addo  ....Call 1 is DISCONNECTED [reason=408 (Request Timeout)]
D/SIP UA Receiver( 2280): < LOCK CPU
D/PowerManagerService(  246): acquireWakeLock flags=0x1 tag=com.csipsimple.inEventLock
D/SIP UA Receiver( 2280): Call state <<
D/SIP UA Receiver( 2280): Updating call infos from the stack
D/PjSipCalls( 2280): Update call 1
D/PjService( 2280): Found pjsua 2 searching 2
D/IPCThreadState(  246): [DN #5] BR_CLEAR_DEATH_NOTIFICATION_DONE cookie 0xeac738
D/PjSipCalls( 2280): Last status code is 408
D/libpjsip( 2280): 16:39:08.659 zrtp_android.c  ....jzrtp_getInfoFromContext : user data 0     

[Anonymous]

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

I have the same problem. While on VPN the media IP used in SDP is the interface IP not the VPN IP. Anyway to use the VPN assigned IP address instead of the phone's WiFi or 3G address?

Thanks!

[Anonymous]

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

Having the same issue. Any way to fix it?

[Anonymous]

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

Please read my comment on issue 2375.
This is not a bug. The SIP control plane and the media plane are not necessarily using the same interface/route in SIP. Some network topologies could require what's done by pjsip currently.
The only correct safe and reliable solution for multihomed is to use ICE and to have all parts supporting ICE. Or have a stun server on your sip server reachable from everywhere your client can connect.
(ICE basically gives candidates IP:port that remote can try to reach you).

Assuming you should be reached by the same interface than the VPN only because the sip server is also reachable using this interface is an assumption you do based on your topology. It's defined nowhere in SIP RFC that it should go this way and there is valid SIP topology where it should not go this way.

Read my comment on issue 2375 : there is something that you might find interesting too at the end that will allow to workaround this case : pjsip guys introduced an option to select the same ip than sip control plan in case you are in your topology case. However, you have to keep in mind it will be a workaround and that your topology is not stable without usage of ICE. (I mean other sip clients could reach same problems because they have no clue on your topology).

Mergedinto: 2375
Status: Duplicate