[B2G][Buri][Dialer] No call waiting notifications

RESOLVED DUPLICATE of bug 897100

Status

Firefox OS
RIL
RESOLVED DUPLICATE of bug 897100
4 years ago
4 years ago

People

(Reporter: Lucas Aliaga, Assigned: hsinyi)

Tracking

(Blocks: 1 bug, {regression})

unspecified
1.2 C3(Oct25)
ARM
Gonk (Firefox OS)
regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: burirun1, burirun2,)

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 805446 [details]
Logcat_CallWaiting.txt

While in a call with a 2nd device, if a 3rd device calls during the active call, no notifications indicating call waiting are presented to the user. Only after the initial call of devices 1 and 2 ends will device 1 show the 3rd devices call.

Repro Steps:
1) Updated Buri to MozBuild ID: 20130916040205 on 3 devices with call waiting set to ON.
2) Device 1 calls Device 2 and device 2 answers.
3) While the call is active, Device 3 calls device 1.

Actual:
Device 1 has no indication of call waiting during an active call.

Expected:
While in a call with a second device, Device 1 displays Device 3's number and the ability to accept the call. Accompanied by a call waiting beep and potentially vibrate.

Environmental Variables
Build ID: 20130916040205
Gecko: http://hg.mozilla.org/mozilla-central/rev/c4bcef90cef9
Gaia: a0079597d510ce8ea0b9cbb02c506030510b9eeb
Platform Version: 26.0a1

Notes:
Repro frequency: 3/3
See attached: Logcat_CallWaiting.txt, http://youtu.be/bvqp4Q2oTYc
I'm imaging we can't get a regression window here for this specific because this has been broken by a different issue specific to hamachi.
blocking-b2g: --- → koi?
Keywords: regression

Updated

4 years ago
Blocks: 835093
No longer depends on: 835093

Updated

4 years ago
Whiteboard: burirun1
Component: Gaia::Dialer → DOM: Device Interfaces
Product: Boot2Gecko → Core
This is a gecko issue
blocking-b2g: koi? → koi+
(Assignee)

Comment 3

4 years ago
I cannot reproduce it on Buri with

gecko, mozillaorg/master (github): e55134bbc72b63f7f81be776158e653c23eedbc8
gaia, mozillaorg/master: eaae9cdb28b1fb28eddbb562b205c676e5bc1eb2

attachment 805446 [details] has no ril debug messages. Please help provide ril messages when reproducing this!

Updated

4 years ago
Component: DOM: Device Interfaces → RIL
Product: Core → Boot2Gecko
(Assignee)

Comment 4

4 years ago
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3)
> I cannot reproduce it on Buri with
> 
> gecko, mozillaorg/master (github): e55134bbc72b63f7f81be776158e653c23eedbc8
> gaia, mozillaorg/master: eaae9cdb28b1fb28eddbb562b205c676e5bc1eb2
> 
> attachment 805446 [details] has no ril debug messages. Please help provide
> ril messages when reproducing this!

In comment#3, I did ./flash.sh for my buri device with the self-built image. And it worked.
However, if the buri uses the pvt image but with only gecko reflashed with the same commit. The issue happens and looks the same as bug 905941.

Bug 905941 added a new configuration preference to device hamachi (buri), the solution not on gecko but on android-device-hamachi [1]. How could we check if the pvt image covers this fix?

[1] https://github.com/mozilla-b2g/android-device-hamachi/blob/master/full_hamachi.mk

Comment 5

4 years ago
Test on Buri build:
Gaia:     a13c76f8d3c617ee57c302c103da04ed1a6298d1
Gecko:    http://hg.mozilla.org/releases/mozilla-aurora/rev/b34384409be6
BuildID   20130924004002
Version   26.0a2

Step A: After MO first call and connected, MO 2nd one.
Log: MO2nd.txt, time stamp: 12:24, 9/25, 
Symptom: UI is not correct, yet remote line can receive the call. Unable to end the call from Buri dialer similar to bug 917222.

Step B: After MO first call and connected, MT a call to DUT.
Log: MT2nd.txt, time stamp: 12:31, 9/25, 
Symptom: No call waiting UI shows while remote line gets being notified instruction. After end current connected call from Buri, you can see 2nd incoming call dialer page.

Comment 6

4 years ago
Created attachment 809645 [details]
MO2nd.txt

Comment 7

4 years ago
Created attachment 809646 [details]
MT2nd.txt
(Assignee)

Comment 8

4 years ago
Per my previous observation (comment 4), I am wondering if the pvt image is updated as expected.

To correctly update the device property into the image, the existing 'B2G/out/target/product/hamachi/system/' must be cleared before we build a new system. I would like to ask for PVT build owner's help to provide a new image built after clearing 'B2G/out/target/product/hamachi/system/' to make sure the pvt build is updated as expected. It would help us to narrow down and figure out the root cause of that Buri call waiting issue. Thank you.
Flags: needinfo?(joduinn)
Assignee: nobody → htsai
Target Milestone: --- → 1.2 QE1(Oct11)

Comment 9

4 years ago
I think the real problem is our base images don't have this configured.

Joe, can we get an updated base image from the vendor that has ro.moz.ril.extra_int_2nd_call=true ?
Flags: needinfo?(joduinn) → needinfo?(jcheng)
Jack, can you take a look at comment 9? i will talk to you directly as well
Flags: needinfo?(jcheng) → needinfo?(liuyongming)

Updated

4 years ago
Blocks: 921979

Updated

4 years ago
Blocks: 917222
Whiteboard: burirun1 → burirun1, burirun2

Updated

4 years ago
Flags: needinfo?(liuyongming)

Comment 11

4 years ago
Dear Michael, 

What used in buri device is QC RIL, so even set ro.moz.ril.extra_int_2nd_call=true in mozilla RIL , it won't make effect. What do you think about this?

If there is any misunderstanding of it, please point out and give your suggestion to us.

Thanks a lot.
Flags: needinfo?(mwu)

Comment 12

4 years ago
we find this feature is only used in gecko/dom/system/gonk/ril_worker.js when call  REQUEST_GET_CURRENT_CALLS;
we don't find the qcom use this feature;

Updated

4 years ago
Whiteboard: burirun1, burirun2 → burirun1, burirun2, [FT:RIL]

Comment 13

4 years ago
Hsinyi, since the target milestone specified was passed, I moved it to the next milestone. If it's not the target milestone you're seeing, please feel free to change it. Thanks.
Target Milestone: 1.2 C2(Oct11) → 1.2 C3(Oct25)
(Assignee)

Comment 14

4 years ago
Kevin, I think the root cause is the base image. We need vendor's support though the vendor seems have some concerns here. I've asked for Joe's help in communicating with the vendor. 

Hi Joe, any updates here? Thank you!
Flags: needinfo?(jcheng)
(In reply to buri.blff from comment #12)
> we find this feature is only used in gecko/dom/system/gonk/ril_worker.js
> when call  REQUEST_GET_CURRENT_CALLS;
> we don't find the qcom use this feature;

In that case, not a blocker since the Mozilla RIL is not being used in production devices.
blocking-b2g: koi+ → -
(In reply to Alex Keybl [:akeybl] from comment #15)
> (In reply to buri.blff from comment #12)
> > we find this feature is only used in gecko/dom/system/gonk/ril_worker.js
> > when call  REQUEST_GET_CURRENT_CALLS;
> > we don't find the qcom use this feature;
> 
> In that case, not a blocker since the Mozilla RIL is not being used in
> production devices.

Not acceptable. This is QA blocker, which means we're blocked on testing on the Mozilla RIL for this feature.
blocking-b2g: - → koi?

Updated

4 years ago
Keywords: qablocker
QA Wanted - check if this reproduces under the following cases:

1. 1.1 Base Partner Image on Buri (no mozilla modifications)
2. 1.2 Gaia/Gecko latest changes on Buri over a 1.2 Base Partner Image
3. 1.2 Gaia/Gecko on Mozilla RIL on Buri
Keywords: qawanted

Comment 18

4 years ago
It seems like this is an issue that was seen on 1.1. I think this may be a duplicate of bug 897100.

Updated

4 years ago
Status: NEW → RESOLVED
blocking-b2g: koi? → ---
Last Resolved: 4 years ago
Keywords: qablocker, qawanted
Resolution: --- → DUPLICATE
Duplicate of bug: 897100

Updated

4 years ago
Blocks: 933576
partner provided latest build 1104. should have this fixed
Flags: needinfo?(jcheng)

Updated

4 years ago
Flags: needinfo?(mwu)
Whiteboard: burirun1, burirun2, [FT:RIL] → burirun1, burirun2,
You need to log in before you can comment on or make changes to this bug.