Not alerting tone during an established call (call waiting)

VERIFIED WORKSFORME

Status

Firefox OS
Gaia::Dialer
P1
normal
VERIFIED WORKSFORME
5 years ago
5 years ago

People

(Reporter: juanpbf, Unassigned)

Tracking

unspecified
x86_64
Windows 7
Dependency tree / graph

Firefox Tracking Flags

(b2g18 affected, b2g18-v1.0.1 affected)

Details

(Whiteboard: IOT, Spain, Ikura, Chile, khepera_43360 )

(Reporter)

Description

5 years ago
+++ This bug was initially created as a clone of Bug #859354 +++
Tested on Ikura
QC RIL version:
"ro.build.firmware_revision=V1.01.00.01.019.105"
gaia commit:
9648799 Merge pull request #9760 from fcampo/whiteScreen-v1.0.1
gecko commit:
6c835ac Bug 868271 - Should not ignore touchend even if event is preventDefaulted. r=vingtetun, a=tef+




During a voice call, being Call Waiting enabled, a continuos alerting tone is not reproduced when receiving a second voice call (just a one single alert is performed). 

This bug has been reported as blocking issue. 

Steps to reproduce: 

1. Establish voice call
2. Call Waiting enabled
3. Receive a second call 

Current: 
4. Only one alert tone (beep) is played to users, indicating second call

Expected: 

4. A continuous alerting tone (i.e. beep-beep beep-beep beep-beep) should be reproduced. 


Additional note: 

http://developer.android.com/reference/android/media/ToneGenerator.html

public static final int TONE_SUP_CALL_WAITING

Added in API level 1
Call supervisory tone, Call Waiting: CEPT, JAPAN: 425Hz, 200ms ON, 600ms OFF, 200ms ON, 3s OFF... ANSI (IS-95): 440 Hz, 300 ms ON, 9.7 s OFF, (100 ms ON, 100 ms OFF, 100 ms ON, 9.7s OFF ...)


This tone is superimposed on the audio traffic received by the called user.
works on partner buri build with a 105 build
did you wait for some more time to hear the subsequent beep?

and tef?, this bug is with tef+ carried over
blocking-b2g: tef+ → tef?
status-b2g18: fixed → ?
status-b2g18-v1.0.1: fixed → ?
ni? on comment 1
Flags: needinfo?(juan.perezbedmar)
(Reporter)

Comment 3

5 years ago
(In reply to Joe Cheng [:jcheng] from comment #1)

> did you wait for some more time to hear the subsequent beep?
You are right Joe, it was just a matter of waiting some extra time. Anyway, IMHO, the time between each group of "beeps" is too long (4 secs aprox) and should be shorten (but it's clearly not a blocking issue for me)
Flags: needinfo?(juan.perezbedmar)
Hi guys! Right now what it is implemented is this: ANSI (IS-95): 440 Hz, 300 ms ON, 9.7 s OFF, (100 ms ON, 100 ms OFF, 100 ms ON, 9.7s OFF ...), this is, a couple of beeps of 100ms (with another 100ms of silence between them) every 10 seconds.

Updated

5 years ago
status-b2g18: ? → affected
status-b2g18-v1.0.1: ? → affected
David, should we block on this one for 1.0.1? I am tempted to say no, so marking leo? but feel free to renominate if needed.
blocking-b2g: tef? → leo?
Flags: needinfo?(dpv)
Hi, 

Retested with ikura, 1.0.1: 
QC RIL version:
"ro.build.firmware_revision=V1.01.00.01.019.107"
gaia commit:
e980247 Merge pull request #9591 from crdlc/bug-868258
gecko commit:
85cfe31 Backed out changeset 63dfdb7a83c6 (bug 868932) for bustage. a=backout

And it's working ok indeed. "bip-bip" signalling is reproduced [440 Hz, 300 ms ON, 9.7 s OFF, (100 ms ON, 100 ms OFF, 100 ms ON, 9.7s OFF ...)]

bug marked as resolved/fixed
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: needinfo?(dpv)
Resolution: --- → WORKSFORME

Updated

5 years ago
blocking-b2g: leo? → ---

Comment 7

5 years ago
Currently what we're observing, according to khepera_43360:  "The real behaviour I've seen with B02 version is that there IS an alerting tone, and it is repeated every 7seconds, aprox. So, although the separation between tones might be excesive, it is working."

Updated

5 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.