1095503 - Dialer tones are not sent to others during conference call

Status: RESOLVED INVALID

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

Description

[Johan Lorenzo [:jlorenzo]]

STR
1. Make a phone call
2. Receive a call
3. Put them in conference
4. Open the dialer
5. Press one button

Actual result
You hear the dialer tone on the DuT but not on any other phone.

Additional notes:
Tested against today's 2.2 and 2.1.

Gaia-Rev        6295f6acfe91c6ae659712747dd2b9c8f51d0339
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8c23b4f2ba29
Build-ID        20141107001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  39
FW-Date         Thu Oct 16 18:19:14 CST 2014
Bootloader      L1TC00011880

Comment 1

[Johan Lorenzo [:jlorenzo]]

QA wanted to check 2.0

Comment 2

[Doug Sherk (:drs) (inactive)]

[Blocking Requested - why for this release]: Clearly broken functionality.

Comment 3

[Cody Roesch [:croesch]]

This bug does NOT repro on Flame kk build: Flame 2.0 KK

Actual Result: Dialer tones are heard on the other devices in a conference call when tapping numbers on the dialpad of the DUT.

Repro Rate: 0/2

Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141107024312
Gaia: d3e4da377ee448f9c25f908159480e867dfb13f3
Gecko: a41256642115
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 4

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue actually DOES occur on 2.0 Flame (KK and JB).  I think the confusion was that this occurs only when adding a number to the conference call but not when bringing up the dial pad and dialing.  This issue occurs in the earliest available flame build that could use SIM cards.

Lastest 2.0 KK Flame build:
Environmental Variables:
Device: Flame 2.0
BuildID: 20141107125304
Gaia: d3e4da377ee448f9c25f908159480e867dfb13f3
Gecko: b3d72fc179e9
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Earliest available 2.0 Flame build:
Environmental Variables:
Device: Flame 2.0
BuildID: 20140506163010
Gaia: 98ca8c55dbe2f21a8661d0eaa87f34d316c3bc98
Gecko: 4e4e0f502969
Version: 32.0a1 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 5

[Gabriele Svelto [:gsvelto]]

OK, next step is to figure out if we're not starting the tones from the dialer or if it's the RIL that's not sending them out. I'll give this a spin next week.

Comment 6

[Francisco Jordano [:arcturus] [:francisco]]

triage group: blocking since this is a major functionality broken.

If 2.0 needs this, please fix in 2.1 and nominate for 2.0, devices team should be in charge of the uplift.

Comment 7

[Francisco Jordano [:arcturus] [:francisco]]

Hi Doug,

do you consider this could be a RIL problem?

Comment 8

[Doug Sherk (:drs) (inactive)]

This looks like a RIL problem to me. I've verified that we're playing the tone from Gaia when the user taps on the keypad, both inside a conference call, and in a regular call:
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/dialer/keypad.js#L307

Hsin-Yi, could you take a look?

Comment 9

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

I haven't got a chance to check 2.1, but I did check 2.2, where Gecko worked fine that it received startTone/stopTone requests from gaia, then sent those requests to modem and got successful responses.
The path in 2.1 is still trivial that when gecko receives startTone/stopTone requests, gecko forwards that to modem. Based on experiences, it's likely that we send right DTMF tones to carrier but the carrier doesn't send those audio to the remote parties correspondingly.

Could you try to create a conference call with a voicemail call (or other automatic service that requires you to key-in some numbers) and another arbitrary call? then after the conference is made, follow the voice service instruction to key in some numbers, see how it works? If you find the service recognizes your number but the remote party couldn't hear the audio tones, then it could be confirmed that it's carrier's problem. Also, it would be good to record ril log during the test. :)

Comment 10

[Doug Sherk (:drs) (inactive)]

Hsin-Yi, you were correct. Thanks for the suggestion.

I'm closing this as INVALID since this is carrier behavior.