Closed Bug 1095503 Opened 10 years ago Closed 10 years ago

Dialer tones are not sent to others during conference call

Categories

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

defect
Not set
normal

Tracking

(blocking-b2g:2.1+, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED INVALID
2.1 S9 (21Nov)
blocking-b2g 2.1+
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: jlorenzo, Assigned: drs)

Details

(Whiteboard: [planned-sprint c=1])

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
QA wanted to check 2.0
Keywords: qawanted
[Blocking Requested - why for this release]: Clearly broken functionality.
Assignee: nobody → gsvelto
No longer blocks: dialer-most-wanted
blocking-b2g: --- → 2.1?
Target Milestone: --- → 2.1 S8 (7Nov)
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawantedregression
QA Contact: croesch
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Contact: croesch
QA Contact: jmercado
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Contact: jmercado
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.
Whiteboard: [planned-sprint c=]
Target Milestone: 2.1 S8 (7Nov) → 2.1 S9 (21Nov)
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.
blocking-b2g: 2.1? → 2.1+
Whiteboard: [planned-sprint c=] → [planned-sprint c=1]
Flags: in-moztrap?(jlorenzo)
Hi Doug,

do you consider this could be a RIL problem?
Flags: needinfo?(drs.bugzilla)
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?
Flags: needinfo?(drs.bugzilla) → needinfo?(htsai)
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. :)
Flags: needinfo?(htsai)
Hsin-Yi, you were correct. Thanks for the suggestion.

I'm closing this as INVALID since this is carrier behavior.
Assignee: gsvelto → drs.bugzilla
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Flags: in-moztrap?(jlorenzo)
You need to log in before you can comment on or make changes to this bug.