948975 - [Unagi_1.2][Pre-IOT] Multi-party call frozen when receiving and finishing a new incoming call

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[David Palomino [:dpalomino]]

Attachment: multicall screenshot

Gecko: d77ba08
Gaia: 1b67b55
AU: AU_LINUX_GECKO_B2G_ICS_1.2.01.02.00.019.120

STR: 

1. Start a multicall (3 parties involved)
2. Join all the calls (OK)
3. Receive a new call. Previous multicall is on hold (OK)
4. Finish the latest incoming call received (OK)
5. Multicall is frozen (it seems to be resumed, but you cannot hear anything). See screenshot attached

This is a blocker for certification. Nominated to koi?

Comment 1

[Preeti Raghunath(:Preeti)]

David,

Please take a look for Dialer issue.

Comment 2

[David Scravaglieri [:scravag]]

n? ti rik & etienne: please check if it is a gecko or gaia bug and reassign if needed

Comment 3

[Etienne Segonzac (:etienne)]

Not set up to reproduce this bug.

A logcat would probably help a lot determining if it's gaia or ril.

Comment 4

[Sarah Parsons]

Attachment: 948975_logcat

Comment 5

[Sarah Parsons]

I was able to repro this issue on Buri 1.2 BuildID: 20131212004004

BuildID: 20131212004004
Gaia: 6d02039072a2ae5cf9225a6f4c78ed49decfab5c
Gecko: 8bae10bb0aed
Version: 26.0
Base: v1.2_20131209

Comment 6

[Anthony Ricaud (:rik)]

A regression window will help a lot.

Comment 7

[Peter Bylenga [:PBylenga]]

This issue appears to have been occurring since conference calling was fixed on Buri v1.2 COM RIL.

First build where Issue can be reproduced (11-8-2013):

Environmental Variables
Device: Buri v1.2 COM RIL
Build ID: 20131108004004
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/a886c641a306
Gaia: 4cf40fb30c7b8380ea83ed0d4efe043b8b81737f
Platform Version: 26.0
RIL Version: 01.02.00.019.102 
Firmware Version: v1.2_20131115

Last build where issue does not reproduce because it was blocked by not being able to setup a conference call (11-7-2013):

Environmental Variables
Device: Buri v1.2 COM RIL
Build ID: 20131107004003
Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/26f1e160e696
Gaia: 590eb598aacf1e2136b2b6aca5c3124557a365ca
Platform Version: 26.0
RIL Version: 01.01.00.019.281 
Firmware Version: 20131115

Comment 8

[Preeti Raghunath(:Preeti)]

Etinenne,

Please check if the data provided by QA above is sufficient to make progress.

Comment 9

[Preeti Raghunath(:Preeti)]

David,

Just ni you to make sure we can have a patch by 12/20.

Comment 10

[Etienne Segonzac (:etienne)]

This logcat doesn't contain anything gecko or gaia related so we wont be able to make progress here.

But given the symptoms and the regression window my bet would be on a platform issue rather than a gaia one.
So David is not the best contact to make this move forward here.

Comment 11

[Jason Smith [:jsmith]]

Does this reproduce on the latest 1.2 Moz Ril build?

Comment 12

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Does this reproduce on the latest 1.2 Moz Ril build?

Also - Can we get RIL logs when this reproduces?

Comment 13

[Matthew Vaughan]

Attachment: LogCat with RIL debug enabled.

This issue does reproduce for me on the Buri 12/18 1.2 MOZ RIL build.

The attached logcat should have the requested RIL debug information. If it does not then please let me know.

- Buri 1.2 Build -
Environmental Variables:
Device: Buri v1.2 MOZ RIL
BuildID: 20131218004002
Gaia: 38338b31b554cdb8c6242b15a966f171a0e7abaa
Gecko: dcffefec8206
Version: 26.0
Firmware Version: 20131209

Comment 14

[Jason Smith [:jsmith]]

Can we try getting a regression window using Moz RIL 1.2 builds?

Comment 15

[Jason Smith [:jsmith]]

Hsin-Yi - Can check the RIL logs here to see if this the root cause of this bug is RIL-related or not?

Comment 16

[Matthew Vaughan]

This issue started reproducing on the Buri 9/18 1.2 Mozilla RIL build. This is the first Aurora build for 1.2 (when 1.3 master branched off), and is when group calling appears to have first been implemented; it is not possible to start a group call on the 9/17 1.2 build or earlier. 

The issue that I am seeing is what was mentioned in comment 0 under step 5, which is the inability to hear any of the group call audio even though it appears the call was resumed. There is no option in the UI to indicate to the user that there is a way to resume the group call. If the test device ends the group call, then the other devices will be disconnected from each other as well.

- First build with group calling feature -
Environmental Variables:
Device: Buri v1.2 MOZ RIL
BuildID: 20130918004001
Gaia: 9b1b262e8fde58be453fb05ed91c0e93ab86d394
Gecko: 0322470077b7
Version: 26.0a2
Firmware Version: 20131209

Comment 17

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

(In reply to Matthew Vaughan from comment #13)
> Created attachment 8349512 [details]
> LogCat with RIL debug enabled.
> 
> This issue does reproduce for me on the Buri 12/18 1.2 MOZ RIL build.
> 
> The attached logcat should have the requested RIL debug information. If it
> does not then please let me know.
> 
> - Buri 1.2 Build -
> Environmental Variables:
> Device: Buri v1.2 MOZ RIL
> BuildID: 20131218004002
> Gaia: 38338b31b554cdb8c6242b15a966f171a0e7abaa
> Gecko: dcffefec8206
> Version: 26.0
> Firmware Version: 20131209

Hi, thanks for the log. I am expecting to see a bunch of flooding messages labeled "RIL Worker"/"RadioInterfaceLayer"/"RILContentHelper". However, I could see only two lines of RIL Worker messages. I am wondering if the log records the whole test. Please help provide a log covering enough information again, and make sure the base image is up-to-date (should be US-V1.2-Dev-20131209.cfg or later).

Comment 18

[Jason Smith [:jsmith]]

QA Wanted to address comment 17

Comment 19

[Tony Chung [:tchung]]

Matthew, can you please try updating the base image today to 20131209.cfg, and record your results?  we need this done today.  Thanks!

Comment 20

[Matthew Vaughan]

Attachment: Logcat number 2 with RIL debugging on MOZ RIL

Hello,

I tested this issue again using the 12/19 1.2 MOZ RIL build, and it seems that I am only getting what is seen in the first logcat that I provided. I have provided my second logcat from today's testing though, LogCat_RIL2.txt, in case there is something different that may help. 

If the logcat still does not have enough information, would it be possible to get some directions on how to get the needed info? When I tested this yesterday, I manually changed the user.js file as instructed here: https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Changing_preferences . Today, I just allowed our flash script to enable RIL debugging (our default method), which seemed to have outputted a similar log.

Also, I made sure I was on the 20131209 base image when testing today. It is easy to tell since group calling on MOZ RIL doesn't work on the 20131115 base image :).

One thing I feel I should mention... On the MOZ RIL, I am not getting a true "freeze" on the group call UI, but rather more of a blocking issue since I have no way of rejoining the group call after hanging up from a separate received call. I can use any of the buttons in the UI, including the "end call" button to end the group call, and the Home button to go back to the Homescreen and what not. This seems to be a bit different from using the COM RIL where only the group call UI would be frozen and the other callers would need to hang up in order to un-freeze the UI on the test device.

- Buri 1.2 Build -
Environmental Variables:
Device: Buri v1.2 MOZ RIL
BuildID: 20131219004002
Gaia: c82c957e9d4078cd4043de6b7d21a2667a73adf7
Gecko: 7958c38c7afd
Version: 26.0
Firmware Version: US_V1.2_20131209

Comment 21

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

(In reply to Matthew Vaughan from comment #20)
> Created attachment 8350146 [details]
> Logcat number 2 with RIL debugging on MOZ RIL
> 
> Hello,
> 
> I tested this issue again using the 12/19 1.2 MOZ RIL build, and it seems
> that I am only getting what is seen in the first logcat that I provided. I
> have provided my second logcat from today's testing though, LogCat_RIL2.txt,
> in case there is something different that may help. 
> 
> If the logcat still does not have enough information, would it be possible
> to get some directions on how to get the needed info? When I tested this
> yesterday, I manually changed the user.js file as instructed here:
> https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Changing_preferences .
> Today, I just allowed our flash script to enable RIL debugging (our default
> method), which seemed to have outputted a similar log.
> 

It's weird ... the log still have nothing (few things) related to RIL messages. :( So, what message "flooding" looks like? https://bug937773.bugzilla.mozilla.org/attachment.cgi?id=8346322 is a good example. It's very easy to tell there are tens RIL Worker messages.

The "Tips_And_Tricks#Changing_preferences" is the usual way to enable RIL debugging. I heard that very seldom it seems not work though I don't know why. Here is another way: modify "dom/system/gonk/ril_consts.js" and set "this.DEBUG_ALL" to true, then rebuild gecko and flash. Please give a try again. :)

> Also, I made sure I was on the 20131209 base image when testing today. It is
> easy to tell since group calling on MOZ RIL doesn't work on the 20131115
> base image :).
> 
> One thing I feel I should mention... On the MOZ RIL, I am not getting a true
> "freeze" on the group call UI, but rather more of a blocking issue since I
> have no way of rejoining the group call after hanging up from a separate
> received call. I can use any of the buttons in the UI, including the "end
> call" button to end the group call, and the Home button to go back to the
> Homescreen and what not. This seems to be a bit different from using the COM
> RIL where only the group call UI would be frozen and the other callers would
> need to hang up in order to un-freeze the UI on the test device.
> 

As you mentioned you'd discovered different symptoms on mozRIL and comRIL, would you please attach screen shots for them both? It would help us to get more ideas, thanks.

> - Buri 1.2 Build -
> Environmental Variables:
> Device: Buri v1.2 MOZ RIL
> BuildID: 20131219004002
> Gaia: c82c957e9d4078cd4043de6b7d21a2667a73adf7
> Gecko: 7958c38c7afd
> Version: 26.0
> Firmware Version: US_V1.2_20131209

Comment 22

[Jason Smith [:jsmith]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #21)
> (In reply to Matthew Vaughan from comment #20)
> > Created attachment 8350146 [details]
> > Logcat number 2 with RIL debugging on MOZ RIL
> > 
> > Hello,
> > 
> > I tested this issue again using the 12/19 1.2 MOZ RIL build, and it seems
> > that I am only getting what is seen in the first logcat that I provided. I
> > have provided my second logcat from today's testing though, LogCat_RIL2.txt,
> > in case there is something different that may help. 
> > 
> > If the logcat still does not have enough information, would it be possible
> > to get some directions on how to get the needed info? When I tested this
> > yesterday, I manually changed the user.js file as instructed here:
> > https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#Changing_preferences .
> > Today, I just allowed our flash script to enable RIL debugging (our default
> > method), which seemed to have outputted a similar log.
> > 
> 
> It's weird ... the log still have nothing (few things) related to RIL
> messages. :( So, what message "flooding" looks like?
> https://bug937773.bugzilla.mozilla.org/attachment.cgi?id=8346322 is a good
> example. It's very easy to tell there are tens RIL Worker messages.
> 
> The "Tips_And_Tricks#Changing_preferences" is the usual way to enable RIL
> debugging. I heard that very seldom it seems not work though I don't know
> why. Here is another way: modify "dom/system/gonk/ril_consts.js" and set
> "this.DEBUG_ALL" to true, then rebuild gecko and flash. Please give a try
> again. :)

Note - the testing our contractors do relies on production builds, not manually generated builds. Naoki could help with this for testing if he manually generates the build, although I think it will be faster for someone who already has a build environment setup to do this in Taipei.

Comment 23

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

Attachment: log-948975-5 - mozRIL: hang up the 3rd call

buri base image: US-V1.2-Dev-20131209.cfg
gaia: mozillaorg/v1.2, 97e775b66c379e252c7b286161d6ed7ce84bbc10 (Dec. 19)
gecko: mozillaorg/v1.2, d44859975b7614b8bb00676b12443edefe71c3ab (Dec. 18)

STR:
1) buri makes the 1st outgoing call (number: 117) and remote party accepts it
2) buri makes the 2nd outgoing call (number: 0916259153) and remote party accepts it
3) merge the calls into conference
4) 3rd remote party (number: 0287861070) calls in
5) Hold the conference on hold and accept the 3rd call
6) Hang up the 3rd call

Then UI frozen ...

Comment 24

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #23)
> Created attachment 8350519 [details]
> log-948975-5 - mozRIL: hang up the 3rd call
> 
> buri base image: US-V1.2-Dev-20131209.cfg
> gaia: mozillaorg/v1.2, 97e775b66c379e252c7b286161d6ed7ce84bbc10 (Dec. 19)
> gecko: mozillaorg/v1.2, d44859975b7614b8bb00676b12443edefe71c3ab (Dec. 18)
> 
> STR:
> 1) buri makes the 1st outgoing call (number: 117) and remote party accepts it
> 2) buri makes the 2nd outgoing call (number: 0916259153) and remote party
> accepts it
> 3) merge the calls into conference
> 4) 3rd remote party (number: 0287861070) calls in
> 5) Hold the conference on hold and accept the 3rd call
> 6) Hang up the 3rd call
> 
> Then UI frozen ...

Right after step 5), I see dialer somehow calls |mozTelephony.dial("0916259153")| again. Please also refer to line# 2594 of the attachment. Seems we need gaia folks help check this part.

Comment 25

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

Attachment: log-948975-6 - mozRIL: remote releases the 3rd call

buri base image: US-V1.2-Dev-20131209.cfg
gaia: mozillaorg/v1.2, 97e775b66c379e252c7b286161d6ed7ce84bbc10 (Dec. 19)
gecko: mozillaorg/v1.2, d44859975b7614b8bb00676b12443edefe71c3ab (Dec. 18)

STR:
1) buri makes the 1st outgoing call (number: 117) and remote party accepts it
2) buri makes the 2nd outgoing call (number: 0916259153) and remote party accepts it
3) merge the calls into conference
4) 3rd remote party (number: 0287861126) calls in
5) Hold the conference on hold and accept the 3rd call
6) Remote party releases the 3rd call

Then UI frozen ...

Comment 26

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

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #25)
> Created attachment 8350524 [details]
> log-948975-6 - mozRIL: remote releases the 3rd call
> 
> buri base image: US-V1.2-Dev-20131209.cfg
> gaia: mozillaorg/v1.2, 97e775b66c379e252c7b286161d6ed7ce84bbc10 (Dec. 19)
> gecko: mozillaorg/v1.2, d44859975b7614b8bb00676b12443edefe71c3ab (Dec. 18)
> 
> STR:
> 1) buri makes the 1st outgoing call (number: 117) and remote party accepts it
> 2) buri makes the 2nd outgoing call (number: 0916259153) and remote party
> accepts it
> 3) merge the calls into conference
> 4) 3rd remote party (number: 0287861126) calls in
> 5) Hold the conference on hold and accept the 3rd call
> 6) Remote party releases the 3rd call
> 
> Then UI frozen ...

Very similar to comment 24:
Right after step 5), I see dialer somehow calls |mozTelephony.dial("0916259153")| again. Please also refer to line# 5706 of the attachment. 

Also, I noticed a potential dialer error:
[JavaScript Error: "TypeError: this.node is null" {file: "app://communications.gaiamobile.org/dialer/js/handled_call.js" line: 212}] (see line# 5876)

Still, seems we need gaia folks to help check this part.

Comment 27

[Etienne Segonzac (:etienne)]

Thanks you so much Hsin-Yi, almost happy to see a JS error, it means I have something to chew on :)
I'll have a look today.

Comment 28

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

(In reply to David Palomino [:dpv] (PTO 12/20 - 12/30) from comment #0)
> Created attachment 8345934 [details]
> multicall screenshot
> 
> Gecko: d77ba08
> Gaia: 1b67b55
> AU: AU_LINUX_GECKO_B2G_ICS_1.2.01.02.00.019.120
> 
> STR: 
> 
> 1. Start a multicall (3 parties involved)
> 2. Join all the calls (OK)
> 3. Receive a new call. Previous multicall is on hold (OK)
> 4. Finish the latest incoming call received (OK)
> 5. Multicall is frozen (it seems to be resumed, but you cannot hear
> anything). See screenshot attached
> 

Oh... I just realized that Step 5 seems nothing wrong. Step 3 put the conference call on hold, and the conference state remains even after step 4. That's why the call screen displays grey and we cannot hear anything, because the conference call hasn't be resumed. Or anything made you feel the call has been resumed?

More, I was able to hang up the conference call after step 5.

And note that, we don't support hold/resume function when there's only one (conference) call. See bug 894232.

In summary, this issue seems not a real bug but a feature we haven't supported yet.

> This is a blocker for certification. Nominated to koi?

Comment 29

[Etienne Segonzac (:etienne)]

So if we have to calls, 1 held and 1 active, and the active call hangs up the held call is automatically resumed.

If we have 1 call and 1 conference group this doesn't work (and maybe it should).

That said, we have a safeguard in the dialer to make sure you're always able to resume a single held call by tapping it. This safeguard doesn't work for conference group and it should. I'll send a patch for this part.

Comment 30

[Etienne Segonzac (:etienne)]

Attachment: Gaia PR to let the user resume the conference group

Comment 31

[Jason Smith [:jsmith]]

Seems like we've got the logs & a path forward here now, so removing qawanted.

Comment 32

[Etienne Segonzac (:etienne)]

Comment on attachment 8350572 [details] [review]
Gaia PR to let the user resume the conference group

Redirecting to Rik because of Spanish holiday + koi+

Comment 33

[Anthony Ricaud (:rik)]

Comment on attachment 8350572 [details] [review]
Gaia PR to let the user resume the conference group

Looks good for 1.2.

I think we have other bugs on master (related to the "call ended" feature). I'll open bugs for that though since it's a separate issue.

Comment 34

[Jason Smith [:jsmith]]

Etienne - Can you land this?

Comment 35

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/7354e63bc91309895b85ca711baa5caff2991c73

Comment 36

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 7354e63bc91309895b85ca711baa5caff2991c73 to:
v1.3: c7dd268ccb330413e3fbdb0dcd12b9c5c442834d
v1.2: a4c9d0e32c75e4dcc4dea78a18b152a2394053c9

Comment 37

[isabelrios]

Hi, 

Unforutunatelly I am still able to reproduce this issue.

With buri device latest base build on both 1.2 and 1.3 builds, although with different behaviours.

1.2 01/16 build:
Gecko-4ab7427
Gaia-539a25e

After step 4, the multi-call seems to be frozen as in the attached, but tapping on 'Gruop call' it is recovered correctly.

1.3 01/16 build:
Gecko-0f53789
Gaia-423326d

After step 3, the device shows 'Call ended' although the call is stablished ok (see new screenshot attached) The screen is frozen, also the dialer app itself, it is necessary to power the device off and on to get it working back.

Should I re-open this bug or file a new one? 
Thanks

Comment 38

[Jason Smith [:jsmith]]

File a new bug.

Comment 39

[isabelrios]

Attachment: Call ended label with the call ongoing

Comment 40

[isabelrios]

New bug created Bug 960507