1035130 - [Dolphin][V1.4][Conference Call]Failed to complete conference call request.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[sam.hua]

Steps:
1) Make a dedicated call from SIM1.
2) Now make MTC on Dolphin.
3) Pick the second call. 
3) Now Dolphin fail to merge call from MMI .

BuildID:
gecko: a149b5fda3d60b309cd1da8c4cf4b4c9905e384e
gaia : 76e669c6fa387f97bcaaaee5d179ee4a9dcca986

Comment 1

[sam.hua]

Attachment: radio.log

Comment 2

[sam.hua]

Attachment: main.log

Comment 3

[sam.hua]

1. MTPY has been established
06-26 13:29:36.689   126   188 D use-Rlog/RLOG-AT: [w] Channel2: AT< +CLCC: 1,0,0,0,1,"[phone]",145
06-26 13:29:36.689   126   188 D use-Rlog/RLOG-AT: [w] Channel2: AT< +CLCC: 2,1,0,0,1,"[phone]",145
06-26 13:29:36.689   126   188 D use-Rlog/RLOG-AT: [w] Channel2: AT< OK
06-26 13:29:36.689   126   568 D use-Rlog/RLOG-RILC: [w] [2855]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}


2. The second mpty requset is reject
06-26 13:29:36.789   126   572 D use-Rlog/RLOG-AT: [w] Channel1: AT> AT+CHLD=3
06-26 13:29:36.809   126   188 D use-Rlog/RLOG-AT: [w] Channel1: AT< +CME ERROR: 3

3. MPTY is held by user
06-26 13:29:37.190   126   569 D use-Rlog/RLOG-RILC: [w] [2857]> SWITCH_WAITING_OR_HOLDING_AND_ACTIVE 
06-26 13:29:37.190   126   569 D use-Rlog/RLOG-RIL: [w] onRequest: SWITCH_WAITING_OR_HOLDING_AND_ACTIVE sState=4
06-26 13:29:37.190   126   569 D use-Rlog/RLOG-RIL: [w] channel1 state: '0' 
06-26 13:29:37.190   126   569 D use-Rlog/RLOG-RIL: [w] get Channel ID '1'
06-26 13:29:37.190   126   569 D use-Rlog/RLOG-AT: [w] Channel1: AT> AT+CHLD=2
06-26 13:29:37.850   126   188 D use-Rlog/RLOG-AT: [w] Channel0: AT< +ECIND: 0,1,1
06-26 13:29:37.850   126   188 D use-Rlog/RLOG-AT: [w] Channel1: AT< OK
06-26 13:29:37.850   126   569 D use-Rlog/RLOG-RILC: [w] [2857]< SWITCH_WAITING_OR_HOLDING_AND_ACTIVE

Comment 4

[sam.hua]

Please help to check:
1. RILC --> Gecko
06-26 13:29:36.679   126   188 D use-Rlog/RLOG-AT: [w] Channel1: AT< +CLCC: 1,0,0,0,1,"[phone]",145
06-26 13:29:36.679   126   188 D use-Rlog/RLOG-AT: [w] Channel1: AT< +CLCC: 2,1,0,0,1,"[phone]",145
06-26 13:29:36.679   126   188 D use-Rlog/RLOG-AT: [w] Channel1: AT< OK
06-26 13:29:36.679   126   569 D use-Rlog/RLOG-RILC: [w] [2854]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}

but: It isn't handled as conference call
06-26 13:29:36.699   111   478 I Gecko   : RIL Worker: [0] Solicited response for request type 9, token 2854, error 0
06-26 13:29:36.699   111   478 I Gecko   : RIL Worker: [0] Handling parcel as REQUEST_GET_CURRENT_CALLS
06-26 13:29:36.699   111   111 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callStateChange","call":{"state":0,"callIndex":1,"toa":145,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"[phone]","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isOutgoing":true,"isEmergency":false,"isConference":false,"started":1403767765243},"rilMessageClientId":0}

Comment 5

[shawn ku [:sku]]

13:29:33.156 : 1 Active + 1 Hole at , and user request CONFERENCE at .
13:29:35.218 : request 1st CONFERENCE
13:29:36.038 : request 2nd CONFERENCE

13:29:36.659 : 1st conference response back
13:29:36.669 : error for 2nd conference call request
13:29:36.679 : now rild know we have both active calls 

13:29:36.789 : 3rd conference call request
13:29:36.809 : error for 3rd conference calls request due to pre-condition not match. ()

13:29:37.890 : why change status to holding for both calls????


06-26 13:29:33.156   126   569 D use-Rlog/RLOG-RILC: [w] [2851]< GET_CURRENT_CALLS {[id=1,HOLDING,toa=145,norm,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,norm,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}

06-26 13:29:35.218   126   568 D use-Rlog/RLOG-RILC: [w] [2852]> CONFERENCE
...
06-26 13:29:36.038   126   572 D use-Rlog/RLOG-RILC: [w] [2853]> CONFERENCE

06-26 13:29:36.659   126   568 D use-Rlog/RLOG-RILC: [w] [2852]< CONFERENCE
06-26 13:29:36.669   126   568 D use-Rlog/RLOG-RILC: [w] [2855]> GET_CURRENT_CALLS
06-26 13:29:36.669   126   572 D use-Rlog/RLOG-RILC: [w] [2853]< CONFERENCE fails by E_GENERIC_FAILURE
06-26 13:29:36.679   126   569 D use-Rlog/RLOG-RILC: [w] [2854]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}
06-26 13:29:36.689   126   568 D use-Rlog/RLOG-RILC: [w] [2855]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}

...

06-26 13:29:36.789   126   572 D use-Rlog/RLOG-RILC: [w] [2856]> CONFERENCE
06-26 13:29:36.809   126   572 D use-Rlog/RLOG-RILC: [w] [2856]< CONFERENCE fails by E_GENERIC_FAILURE

06-26 13:29:37.890   126   568 D use-Rlog/RLOG-RILC: [w] [2858]< GET_CURRENT_CALLS {[id=1,HOLDING,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,HOLDING,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}
06-26 13:29:37.890   126   572 D use-Rlog/RLOG-RILC: [w] [2859]< GET_CURRENT_CALLS {[id=1,HOLDING,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,HOLDING,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}

Comment 6

[shawn ku [:sku]]

For conference call request in a row case, it should be improvable, but not critical.

For the 3rd conference call request, modem return failure is acceptable, but call status change is weird to me.

Comment 7

[shawn ku [:sku]]

Hi Hsinyi/Aknow:
 Could you please help check why RIL reports both call Active (and conference), but gecko handles it as not in conference call?



06-26 13:29:36.679   126   569 D use-Rlog/RLOG-RILC: [w] [2854]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}
06-26 13:29:36.689   126   568 D use-Rlog/RLOG-RILC: [w] [2855]< GET_CURRENT_CALLS {[id=1,ACTIVE,toa=145,conf,mo,als=0,voc,noevp,[phone],cli=0,name='(null)',0][id=2,ACTIVE,toa=145,conf,mt,als=0,voc,noevp,[phone],cli=0,name='(null)',0}

...

06-26 13:29:36.699   111   111 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callStateChange","call":{"state":0,"callIndex":1,"toa":145,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"[phone]","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isOutgoing":true,"isEmergency":false,"isConference":false,"started":1403767765243},"rilMessageClientId":0}
06-26 13:29:36.729   111   111 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callStateChange","call":{"state":0,"callIndex":2,"toa":145,"isMpty":false,"isMT":true,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"[phone]","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isConference":false,"started":1403767773195},"rilMessageClientId":0}
06-26 13:29:36.779   111   111 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callStateChange","call":{"state":0,"callIndex":1,"toa":145,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"[phone]","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isOutgoing":true,"isEmergency":false,"isConference":false,"started":1403767765243},"rilMessageClientId":0}
06-26 13:29:36.779   111   111 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"callStateChange","call":{"state":0,"callIndex":2,"toa":145,"isMpty":false,"isMT":true,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"[phone]","numberPresentation":0,"name":null,"namePresentation":0,"uusInfo":null,"isConference":false,"started":1403767773195},"rilMessageClientId":0}

Comment 8

[Ivan Tsay (:ITsay)]

Hi Pei-pei,

Does this happen on Flame?

Comment 9

[Peipei Cheng (needinfo if you need my action)]

I didn't reproduce this on both dolphin and flame. 

Sam, I tried FIREFOXOS_V1.4_W14.28.1_SP7715 dolphin build but cannot reproduce this. Are you sure your SIM card support conference call?

Comment 10

[sam.hua]

gaia should send two conference request and then hold it.

so please click it quickly.

http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=327677

Comment 11

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 1: Only accept one conference request at a time

Comment 12

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 2: Add test to send conference request twice

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8452850 [details] [diff] [review]
Part 1: Only accept one conference request at a time

Review of attachment 8452850 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/ril_worker.js
@@ +1864,5 @@
> +      // Only accept one conference request at a time..
> +      if (this._hasConferenceRequest) {
> +        options.success = false;
> +        options.errorName = "addError";
> +        options.errorMsg = RIL_ERROR_TO_GECKO_ERROR[options.rilRequestError];

options.rilRequestError undefined.

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8452851 [details] [diff] [review]
Part 2: Add test to send conference request twice

Review of attachment 8452851 [details] [diff] [review]:
-----------------------------------------------------------------

Nice! Thank you.

Comment 15

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: Part 1#2: Only accept one conference request at a time

Comment 16

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #14)
> Comment on attachment 8452851 [details] [diff] [review]
> Part 2: Add test to send conference request twice
> 
> Review of attachment 8452851 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Nice! Thank you.

For part2, I have renamed the test case to "test_conference_add_twice_error.js". It is also added into manifest.

Comment 17

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8452942 [details] [diff] [review]
Part 1#2: Only accept one conference request at a time

Review of attachment 8452942 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you!

Comment 18

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: [final] Part 1: Only accept one conference request at a time. r=hsinyi

Comment 19

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: [final] Part 2: Add test to send conference request twice. r=hsinyi

Comment 20

[Szu-Yu Chen [:aknow] (inactive)]

https://tbpl.mozilla.org/?tree=Try&rev=c3310ded4788

Comment 21

[Wayne Chang [:wchang]]

bhavana,

this seems generic, might want to consider for 2.0 onwards.

Comment 22

[Szu-Yu Chen [:aknow] (inactive)]

Attachment: (1.4) [final] Only accept one conference request at a time. r=hsinyi

I think that we could only land part 1 on v1.4.
There is a big difference on testing code between master and 1.4. It's not easy to migrate the test case.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/81abb9a43f2c
https://hg.mozilla.org/integration/b2g-inbound/rev/48a8caaf166a

Please refrain from testing all platforms for code changes that are clearly B2G-only. Doing so needlessly consumes tremendous resources and contributes to ongoing backlog problems that affect all other developers.
https://wiki.mozilla.org/Sheriffing/How:To:Recommended_Try_Practices

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/81abb9a43f2c
https://hg.mozilla.org/mozilla-central/rev/48a8caaf166a

Comment 25

[Szu-Yu Chen [:aknow] (inactive)]

try for 1.4
https://tbpl.mozilla.org/?tree=Try&rev=12afba3113fc

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/831c8f1aadc2

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/1f50cc1bb505
https://hg.mozilla.org/releases/mozilla-aurora/rev/69340019902d

Comment 28

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

There is a valid testcase that covers this bug: https://moztrap.mozilla.org/manage/case/9054/