Description: When user disable the Mic, pulling down the notification bar will still display the Mic is enable Setup: - Install the Loop app on two devices from: https://github.com/mozilla-b2g/firefoxos-loop-client - Sign into Loop app using Firefox Accounts Repro Steps: 1) Update a Flame to 20140812000205 2) On both Devices: Confirm devices have contacts added containing Firefox Account email 3) Select Loop App> Select Contact Icon(base of screen) 4) Make a call from the contact 5) While on the call, tap the '...' 6) Tap the Mic icon > pull down the notification bar Actual: Mic display enable when it is disable Expected: Mic is disable Environmental Variables: Device: Flame 2.0 Build ID: 20140812000205 Gaia: 1144cdc3a544f81c9bf71598aba1cb67d6c95a29 Gecko: 6495a7bd61ed Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Note: the mic is on before disabling, mic is still on afterwards Repro frequency: 3/3 See attached: screenshot and logcat attached

This issue also reproduce on Flame 2.1 (319mb), Buri 2.1, Flame 2.0 (512mb), Buri 2.0. Mic display enable when it is disable. Flame 2.1 (319mb) Environmental Variables: Device: Flame Master Build ID: 20140812040201 Gaia: e78e62125eb43c3a28cdc047987ba54430694a2f Gecko: b53c2753ce9a Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Buri 2.1 Environmental Variables: Device: Buri Master Build ID: 20140812073020 Gaia: e78e62125eb43c3a28cdc047987ba54430694a2f Gecko: ee1ad12a3939 Version: 34.0a1 (Master) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.0 (512mb) Environmental Variables: Device: Flame 2.0 Build ID: 20140812000205 Gaia: 1144cdc3a544f81c9bf71598aba1cb67d6c95a29 Gecko: 6495a7bd61ed Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Buri 2.0 Environmental Variables: Device: Buri 2.0 Build ID: 20140812063006 Gaia: 88e774c606520c9ce349b467866e200e8db31af4 Gecko: d37b1bd92b3d Version: 32.0 (2.0) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 _________________________________________________________________________________________________________________________ This issue does not reproduce on the Flame 1.4 (319mb), Buri 1.4, and the Buri 1.3 because the feature was not implemented. Flame 1.4 (319mb) Environmental Variables: Device: Flame 1.4 Build ID: 20140812063005 Gaia: ec395d47cee9234ae93d2410d8ef8724dfc5d6cb Gecko: 5b219153e2f4 Version: 30.0 (1.4) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 Buri 1.4 Environmental Variables: Device: Buri 1.4 BuildID: 20140812063005 Gaia: ec395d47cee9234ae93d2410d8ef8724dfc5d6cb Gecko: 5b219153e2f4 Version: 30.0 (1.4) Firmware: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 Buri 1.3 Environmental Variables: Device: Buri 1.3 BuildID: 20140811024001 Gaia: 23f55be856cef53c6604a6fe4aeb09061afbc897 Gecko: ac685e277c7c Version: 28.0 (1.3) Firmware: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

This issue was found on the Flame 2.0 (319)

mbarone this seems like it could be a possible blocker. Could you weigh in on this issue please?

(In reply to KTucker [:KTucker] from comment #5) > mbarone this seems like it could be a possible blocker. Could you weigh in > on this issue please? The issue here is that when muting the call, the Loop App is still accessing the microphone, as the TB SDK is still accessing it, because of that, the recording indication is still shown. We don't think it's a blocker and furthermore, there is little we can't do in order to solve this.

Setting ni to me, to remind me to check the status of this issue

Hi all, Dut to TB SDK we are requesting both Streams (audio and video), and internally we are stopping video/audio by request through Loop UI. This means that we are always asking permissions for both (regardless we use them or not), because we can enable during the call. This is due to currently we can not change the constraints 'on the fly' during a WebRTC call. I hope it helps!

Pete, in this case it seems that there is no solution for this due to WebRTC does not support changing the constraints on the fly, and with TB we are requesting all streams for doing a workaround to that missing functionality (so nothing we can do at Loop level) Should we close this bug? Thanks!

Borja, yeah if that is the case then I think that this bug should be closed

Fixing this could imply a significant amount of work, involving Tokbox, Loop app and perhaps Platform, so we can not fix it for first Loop version.