Closed Bug 1095503 Opened 7 years ago Closed 7 years ago
Dialer tones are not sent to others during conference call
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
[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?]
QA Contact: croesch
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?] → [QAnalyst-Triage+]
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]
Hi Doug, do you consider this could be a RIL problem?
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. :)
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: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.