Downloading not resumed after call release |
||||||||
Issue description[Restrict-View-Google] Device : Samsung phone : Android N OS Chrome Version : 58.0.3029.83 URLs (if applicable) : ms.tmotest.net/ftp What steps will reproduce the problem? 1. Using browser go to ms.tmotest.net/ftp and download 300mb file. 2. During PS downloading perform MO/MT call to DUT. 3. Observe proper CSFB and PS suspend. 4. Release call and check if file DL is resumed. What is the expected result? File transfer should be active in 3G call or resume right after call release. What happens instead? PS downloading suspended after LTE 2 WCDMA CSFB and not continue after call release. Please provide any additional information below. Attach a screenshot if possible. Attaching the logs for reference.
,
Jul 21 2017
,
Jul 21 2017
,
Jul 21 2017
,
Jul 24 2017
This seems to be a critical issue. Can it be checked on priority?
,
Jul 27 2017
,
Aug 1 2017
I don't quite understand a lot of terms used in the bug description. What is MO/MT call? What is CSFB and PS? And how the download is initiated? is it thru LTE or on wifi network?
,
Mar 21 2018
Not able to reproduce the issue anymore. Incase it occurs again, will provide the new logs and complete details. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by mili.adl...@samsung.com
, Jul 21 2017From the tcpdump: Downloading started: 55.33 Stop: 56.14 new SYN to proxy and further normal communication 57.57 Call status: // incoming call 8466: 07-19 10:55:56.025 9541 9541 D RILJ : [9087]> GET_CURRENT_CALLS [SUB0] 8531: 07-19 10:55:56.038 9541 10152 D RILJ : [9087]< GET_CURRENT_CALLS {[id=1,INCOMING,toa=129,norm,mt,0,voc,noevp,,cli=1,,1] } [SUB0] // call 8899: 07-19 10:56:01.261 4134 4171 E RILD : [G] RX: (M)CALL_CMD (S)CALL_STATUS (T)NOTI l:d m:db a:00 [ 00 01 00 03 00 00 ] 8930: 07-19 10:56:01.273 9541 9541 D RILJ : [9095]> GET_CURRENT_CALLS [SUB0] 8979: 07-19 10:56:01.280 9541 10152 D RILJ : [9095]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=129,norm,mt,0,voc,noevp,,cli=1,,1] } [SUB0] // call ended 10100: 07-19 10:57:04.573 4134 4171 E RILD : [G] RX: (M)CALL_CMD (S)CALL_STATUS (T)NOTI l:d m:00 a:00 [ 00 01 00 04 00 05 ] 10144: 07-19 10:57:04.601 9541 9541 D RILJ : [9135]> GET_CURRENT_CALLS [SUB0] 10175: 07-19 10:57:04.609 9541 10152 D RILJ : [9135]< GET_CURRENT_CALLS {} [SUB0] // This shows that after the call, data was restored. Moreover when there is new SYN on 57.57 we cannot check what is the destination, becouse we can only see the proxy. // It looks more like downloading app error. // 57:06.015 Data is connected 07-19 10:57:06.015 9541 10152 D RILJ : [9138]< DATA_REGISTRATION_STATE {1, 6204, 01734601, 15, null, 4, 0xcbe2, null, 0x01734601, null, null, 0, 1, 15} [SUB0] 07-19 10:57:06.160 9541 10152 D RILJ : [9144]< DATA_REGISTRATION_STATE {1, 0000, 01734601, 14, null, 4, 0xcbe2, null, 0x01734601, null, null, 0, 1, 14} [SUB0]