+++ 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
(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)
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.
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?
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
Resolution: --- → WORKSFORME
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."
You need to log in before you can comment on or make changes to this bug.