search

r3gis3r / CSipSimple

CSipSimple Mirror (no pull-requests here)
http://www.csipsimple.com
GNU Lesser General Public License v3.0
302 stars 227 forks source link

Outgoing calls have a 5-second delay on Android 6.0, HTC M8, when ICE is enabled. #43

Closed zipcom closed 8 years ago

zipcom commented 8 years ago

Outgoing calls have a 5-second delay on Android 6.0, HTC M8, when ICE is enabled. 05-27 17:08:49.380 26486 26486 E : ====== dialButton pressed ====== 05-27 17:08:54.620 26508 26551 D libpjsip: 17:08:54.621 icetp00 !ICE session created, comp_cnt=2, role is Controlling agent 05-27 17:08:54.620 26508 26551 D libpjsip: INVITE sip:4002@211.75.164.20 SIP/2.0 Without ICE, or with Android 4.0, there is no delay. htc826_ice_delay_5.txt

p00h commented 8 years ago

ICE works that way. You could get any client claiming ICE support, and the result would be the same.

On Tue, 31 May 2016, 07:04 zipcom, notifications@github.com wrote:

Outgoing calls have a 5-second delay on Android 6.0, HTC M8, when ICE is enabled. 05-27 17:08:49.380 26486 26486 E : ====== dialButton pressed ====== 05-27 17:08:54.620 26508 26551 D libpjsip: 17:08:54.621 icetp00 !ICE session created, comp_cnt=2, role is Controlling agent 05-27 17:08:54.620 26508 26551 D libpjsip: INVITE sip:4002@211.75.164.20 SIP/2.0 Without ICE, or with Android 4.0, there is no delay. htc826_ice_delay_5.txt https://github.com/r3gis3r/CSipSimple/files/290230/htc826_ice_delay_5.txt

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/r3gis3r/CSipSimple/issues/43, or mute the thread https://github.com/notifications/unsubscribe/AAIvAjcP9Cg-fzoGQCtBr6uWkAHVn646ks5qG5c5gaJpZM4IqHpi .

zipcom commented 8 years ago

Thanks for the reply. But, pjsip inside PC does not work that way. It dialouts almost immediately. Please note the following timing:

18:17:46.626 pjsua_media.c ..Media index 0 selected for audio call 0 18:17:46.630 icetp00 ICE session created, comp_cnt=2, role is Controlling agent

Using the same CsipSimple code running on Nexus PAD with Android 5.0, comes back with the result as in PC: no delay at all.

A more complete trace follows:

18:17:46.615 dlg01137654 .UAC dialog created 18:17:46.615 dlg01137654 ..Session count inc to 2 by mod-pjsua 18:17:46.616 pjsua_media.c .Call 0: initializing media.. 18:17:46.617 icetp00 ..Creating ICE stream transport with 2 component(s) 18:17:46.621 icetp00 ...Comp 1: host candidate 192.168.123.100:4052 added 18:17:46.621 icetp00 ...Comp 1: host candidate 192.168.211.1:4052 added 18:17:46.621 icetp00 ...Comp 1: host candidate 192.168.28.1:4052 added 18:17:46.625 icetp00 ...Comp 2: host candidate 192.168.123.100:4042 added 18:17:46.625 icetp00 ...Comp 2: host candidate 192.168.211.1:4042 added 18:17:46.625 icetp00 ...Comp 2: host candidate 192.168.28.1:4042 added 18:17:46.625 icetp00 ...ICE stream transport 01137E5C created 18:17:46.626 pjsua_media.c ..Media index 0 selected for audio call 0 18:17:46.630 icetp00 ICE session created, comp_cnt=2, role is Controlling agent 18:17:46.630 icetp00 ICE nomination type set to aggressive 18:17:46.630 icetp00 Candidate 0 added: comp_id=1, type=host, foundation=Hc0a87b64, addr=192.168.123.100:4052, base=192.168.123.100:4052, prio=0x7effffff (2130706431) 18:17:46.630 icetp00 Candidate 1 added: comp_id=1, type=host, foundation=Hc0a8d301, addr=192.168.211.1:4052, base=192.168.211.1:4052, prio=0x7effffff (2130706431) 18:17:46.630 icetp00 Candidate 2 added: comp_id=1, type=host, foundation=Hc0a81c01, addr=192.168.28.1:4052, base=192.168.28.1:4052, prio=0x7effffff (2130706431) 18:17:46.630 icetp00 Candidate 3 added: comp_id=2, type=host, foundation=Hc0a87b64, addr=192.168.123.100:4042, base=192.168.123.100:4042, prio=0x7efffffe (2130706430) 18:17:46.630 icetp00 Candidate 4 added: comp_id=2, type=host, foundation=Hc0a8d301, addr=192.168.211.1:4042, base=192.168.211.1:4042, prio=0x7efffffe (2130706430) 18:17:46.631 icetp00 Candidate 5 added: comp_id=2, type=host, foundation=Hc0a81c01, addr=192.168.28.1:4042, base=192.168.28.1:4042, prio=0x7efffffe (2130706430) 18:17:46.631 dlg01137654 .Session count dec to 2 by mod-pjsua 18:17:46.632 dlg01137654 Module mod-invite added as dialog usage, data=0116E44C 18:17:46.632 dlg01137654 .Session count inc to 4 by mod-invite 18:17:46.632 dlg01137654 Module mod-100rel added as dialog usage, data=0116DDB8 18:17:46.632 dlg01137654 100rel module attached 18:17:46.632 inv01137654 UAC invite session created for dialog dlg01137654

zipcom commented 8 years ago

It seems that pjsip and csipsimple have done the correct things. However, the Android 6.0 AlarmManager delays the "schedule timer" by 5 seconds, as shown in the following trace:

06-03 17:05:25.547 11685 11706 V Timer wrap: Schedule timer 142 in 0ms @ 147924787 06-03 17:05:30.557 11685 11685 V Timer wrap: FIRE Received TIMER 142 147924787 vs 147929782

Scheduled at 147924787 but fired at 147929782.

Anybody provides clue will be highly appreciated. Thanks.

<> 06-03 17:05:25.537 11685 12399 V libpjsip: 17:05:25.548 opensl_dev.c !Player thread started 06-03 17:05:25.537 11685 11706 V libpjsip: 17:05:25.548 stuntp0xab755a !...SO_RCVBUF set to 212992 06-03 17:05:25.537 11685 11706 V libpjsip: 17:05:25.548 stuntp0xab755a ...SO_SNDBUF set to 212992 06-03 17:05:25.537 11685 11706 D libpjsip: 17:05:25.551 icetp00 ...Comp 1: host candidate 192.168.123.101:4028 added 06-03 17:05:25.537 11685 11706 V libpjsip: 17:05:25.551 stuntp0xab7726 ...SO_RCVBUF set to 212992 06-03 17:05:25.537 11685 11706 V libpjsip: 17:05:25.551 stuntp0xab7726 ...SO_SNDBUF set to 212992 06-03 17:05:25.547 11685 11706 D libpjsip: 17:05:25.558 icetp00 ...Comp 2: host candidate 192.168.123.101:4010 added 06-03 17:05:25.547 11685 11706 D libpjsip: 17:05:25.558 icetp00 ...ICE stream transport 0xab83ab64 created 06-03 17:05:25.547 11685 11706 V libpjsip: 17:05:25.558 timer_android. ...Scheduling timer 15 of 1 in 0 ms @ 0xab82b250 06-03 17:05:25.547 11685 11706 V Timer wrap: Schedule timer 142 in 0ms @ 147924787 06-03 17:05:25.547 11685 11706 D libpjsip: 17:05:25.562 pjsua_media.c ..Media index 0 selected for audio call 0 06-03 17:05:25.547 11685 11706 D PjService: DTMF - Store for 0 - null 06-03 17:05:25.557 11685 11706 E PjService: ====== makecall pjsua.pj_pool_release ====== 06-03 17:05:25.557 11685 11706 E SIP SRV : ====== SipServiceExecutor s.sipWakeLock.release ====== 06-03 17:05:25.557 11685 11706 V SipWakeLock: release wakelock: holder count=0 06-03 17:05:25.667 11685 12400 V libpjsip: 17:05:25.673 opensl_dev.c !Recorder thread started 06-03 17:05:30.557 11685 11685 V Timer wrap: FIRE Received TIMER 142 147924787 vs 147929782 06-03 17:05:30.557 11685 11685 E Timer wrap: ====== TimerJob wakeLock.acquire ====== 06-03 17:05:30.557 11685 11685 V SipWakeLock: acquire wakelock: holder count=1 06-03 17:05:30.557 11685 12221 V Timer wrap: FIRE START 142 06-03 17:05:30.557 11685 12221 V libpjsip: 17:05:30.566 timer_android. !FIRE timer 15 of heap 1

zipcom commented 8 years ago

This 5-second delay is actually a very serious problem with "User Experience". It could lead to a general reject of CsipSimple from the Android 6.0 marketplace.

Is there any "real" user of CsipSimple anyway as of today? Or, CsipSimple has been abandoned completely?

gtjoseph commented 8 years ago

Try turning off "Resolve DNS SRV" under Network.

On Sun, Jun 5, 2016 at 11:44 PM, zipcom notifications@github.com wrote:

This 5-second delay is actually a very serious problem with "User Experience". It could lead to a general reject of CsipSimple from the Android 6.0 marketplace.

Is there any "real" user of CsipSimple anyway as of today? Or, CsipSimple has been abandoned completely?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/r3gis3r/CSipSimple/issues/43#issuecomment-223873048, or mute the thread https://github.com/notifications/unsubscribe/ABJlova9q6qtRyIsVE0-FvuK4He4TBFQks5qI7O9gaJpZM4IqHpi .

zipcom commented 8 years ago

Thanks Joseph. I tried both on/off "Resolve DNS SRV" under Network. No difference.

It seems that Android 6.0 is THE problem. They changed the AlarmManager API design.

Has anybody encountered the similar problem?

zipcom commented 8 years ago

ICE with Linphone does not have the same problem. Unfortunately, Linphone does not support TURN server. So, in case that both parties are under symmetric NAT, Linphone clients will be out of luck -- no voice or one-way voice, which apparently is much worse than CsipSimple. So, we are still pending, waiting for any solution for CsipSimple. Has anybody ever encountered the same problem?.

zipcom commented 8 years ago

It is apparent that very few APPs enable ICE/TURN/STUN. Most APPs run with Asterisk server or the like, which relays all RTP traffic by default and most ITSPs enable "SIP Server Relay" also by default. So, the NAT/Firewall is a non-issue. Even though ICE/TURN/STUN, are supposedly the international standard to support the least cost RTP routing among P2P and TURN Relay, very few APPs are able to take advantages of it. So, we should consider this Issue as "closed", for lack of response and interest.

Whoever suffers the same problem is encouraged to create another "New Issue".