1087463 - [Loop] FirfoxHello VT call is not routing to BT headset

Status: RESOLVED WONTFIX

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

Description

[Jay]

Pre-Conditions:
1. Connect BT headset with 8x10 device

Steps to reproduce:
1. Make MO Firefox VT call from device1 to device2
2. Establish VT call between device1 and device2 
3. Now disable speaker symbol from the on-going VT call screen

Issue:
Observed audio of VT call is routing to earpiece

Expected behavior:
Audio of VT call should route to BT headset

Comment 1

[Jay]

Maria,

Can you give the update on this?

Comment 2

[Jay]

[Blocking Requested - why for this release]:

Comment 3

[Maria Angeles Oteo (:oteo)]

Yes, I am reproducing this issue too with BT headsets and in 2.0 version
assigning to Carmen so she can start working on it today.

Not sure about the 2.1 nomination, let's investigate first where the issue is happening, in platform or in Loop application. According to it we will unnominate it or not the bug. In fact if it's a platform issue and we can have a fix in time it should be nominated to 2.0.

Comment 4

[Carmen Jimenez Cabezas]

It seems that we don't have a system-wide way of enabling bluetooth headsets. Instead, the call screen app manages that for itself (at [1]). And to do that, it needs the bluetooth permission, which is certified only. 

Now, a stopgap solution for 2.0 could be adding a moz-bluetooth permission (similar as the approach taken for the attention permission [2]). The problem with that is that the bluetooth permission is used for everything bluetooth related, from pairing to enabling a previously paired headset.

A better solution, which is probably too late for 2.0 would be adding a system-wide way of changing the device used for calls, and allowing third party apps to consume this service

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/js/calls_handler.js#L631
[2] https://mxr.mozilla.org/mozilla-central/source/dom/apps/PermissionsTable.jsm#218

Comment 5

[bhavana bajaj [:bajaj]]

(In reply to Carmen Jimenez Cabezas from comment #4)
> It seems that we don't have a system-wide way of enabling bluetooth
> headsets. Instead, the call screen app manages that for itself (at [1]). And
> to do that, it needs the bluetooth permission, which is certified only. 
> 
> Now, a stopgap solution for 2.0 could be adding a moz-bluetooth permission
> (similar as the approach taken for the attention permission [2]). The
> problem with that is that the bluetooth permission is used for everything
> bluetooth related, from pairing to enabling a previously paired headset.
> 
> A better solution, which is probably too late for 2.0 would be adding a
> system-wide way of changing the device used for calls, and allowing third
> party apps to consume this service
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/js/
> calls_handler.js#L631
> [2]
> https://mxr.mozilla.org/mozilla-central/source/dom/apps/PermissionsTable.
> jsm#218

Given we need this urgently and most of these options seem to be in Bluetooth on the platform side, I am NI'ing him to get his thoughts/feedback here.

Comment 6

[shawn ku [:sku]]

Hi Shawn:
 I think Bhavana is indicating you in comment 5, not me.

Please let me know if I got anything wrong here.
Shawn Ku

Comment 7

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Carmen Jimenez Cabezas from comment #4)
> It seems that we don't have a system-wide way of enabling bluetooth
> headsets. Instead, the call screen app manages that for itself (at [1]). And
> to do that, it needs the bluetooth permission, which is certified only. 
> 
> Now, a stopgap solution for 2.0 could be adding a moz-bluetooth permission
> (similar as the approach taken for the attention permission [2]). The
> problem with that is that the bluetooth permission is used for everything
> bluetooth related, from pairing to enabling a previously paired headset.
> 
> A better solution, which is probably too late for 2.0 would be adding a
> system-wide way of changing the device used for calls, and allowing third
> party apps to consume this service
> 
> [1]
> https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/js/
> calls_handler.js#L631
> [2]
> https://mxr.mozilla.org/mozilla-central/source/dom/apps/PermissionsTable.
> jsm#218

The short term solution is to modify PermissionsTable.jsm.

Comment 8

[bhavana bajaj [:bajaj]]

(In reply to Shawn Huang [:shawnjohnjr] from comment #7)
> (In reply to Carmen Jimenez Cabezas from comment #4)
> > It seems that we don't have a system-wide way of enabling bluetooth
> > headsets. Instead, the call screen app manages that for itself (at [1]). And
> > to do that, it needs the bluetooth permission, which is certified only. 
> > 
> > Now, a stopgap solution for 2.0 could be adding a moz-bluetooth permission
> > (similar as the approach taken for the attention permission [2]). The
> > problem with that is that the bluetooth permission is used for everything
> > bluetooth related, from pairing to enabling a previously paired headset.
> > 
> > A better solution, which is probably too late for 2.0 would be adding a
> > system-wide way of changing the device used for calls, and allowing third
> > party apps to consume this service
> > 
> > [1]
> > https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/js/
> > calls_handler.js#L631
> > [2]
> > https://mxr.mozilla.org/mozilla-central/source/dom/apps/PermissionsTable.
> > jsm#218
> 
> The short term solution is to modify PermissionsTable.jsm.

Shawn, other than adding the permission is there any other risk that we will be adding here ? Wanted to guage the risk factor and make sure QA/Tef is aware of testing needed.

Comment 9

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to bhavana bajaj [:bajaj] from comment #8)
> > The short term solution is to modify PermissionsTable.jsm.
> Shawn, other than adding the permission is there any other risk that we will
> be adding here ? Wanted to guage the risk factor and make sure QA/Tef is
> aware of testing needed.
I will ask Paul and Jonas to evaluate risks, move discussion to Bug 1090137.

Comment 10

[Carmen Jimenez Cabezas]

Attachment: V1 Proposed patch

Comment 11

[Carmen Jimenez Cabezas]

I uploaded a patch that allows audio to be played on the BT headphones (need the Gecko patch from bug 1090137, though). There's currently no way of getting the input from a BT headset microphone though

Comment 12

[José Antonio Olivera Ortega [:jaoo]]

We would need patch from bug 1090137 uplifted to gecko 32.0 branch, wouldn't we? IMHO we should not take the patch here until patch from bug 1090137 get uplifted to gecko 32.0 branch as well.

Comment 13

[Maria Angeles Oteo (:oteo)]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #12)
> We would need patch from bug 1090137 uplifted to gecko 32.0 branch, wouldn't
> we? IMHO we should not take the patch here until patch from bug 1090137 get
> uplifted to gecko 32.0 branch as well.

For 2.0 it's not necessary, Loop Mobile client 1.1 and 1.1.1 releases will be delivered on FxOS 2.0 version and are specific for a target country where the BT headset use seems not to be a blocking requirement.

Next 2.0 Loop Mobile Client version is not confirmed if it will go over 2.1 or 2.2 FxOS. Anyway, analyzing with Carmen the solution proposed in the patch (thanks a lot Carmen for your work!), is not good enough to be delivered in 2.1. We would be able to redirect the audio of the Loop call through the BT headsets but we can not do the same with the BT micro that will continue not working, so we would offer a half functionality... 

In that case, I think the best is trying to offer a complete solution in gecko to handle this properly and try to have it ready for 2.2. Bug 1091417 - Investigate to design Bluetooth SCO connection (bluetooth voice call audio) API for WebRTC/VoIP/Voice Dialing use cases, could be a good starting point.

Jay, Bhavana, I think the best is leaving this for 2.1 and focusing in a complete solution for 2.2 and remove the 2.1+ flag, do you agree with it?

Comment 14

[Jay]

(In reply to Maria Angeles Oteo (:oteo) from comment #13)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #12)
> > We would need patch from bug 1090137 uplifted to gecko 32.0 branch, wouldn't
> > we? IMHO we should not take the patch here until patch from bug 1090137 get
> > uplifted to gecko 32.0 branch as well.
> 
> For 2.0 it's not necessary, Loop Mobile client 1.1 and 1.1.1 releases will
> be delivered on FxOS 2.0 version and are specific for a target country where
> the BT headset use seems not to be a blocking requirement.
> 
> Next 2.0 Loop Mobile Client version is not confirmed if it will go over 2.1
> or 2.2 FxOS. Anyway, analyzing with Carmen the solution proposed in the
> patch (thanks a lot Carmen for your work!), is not good enough to be
> delivered in 2.1. We would be able to redirect the audio of the Loop call
> through the BT headsets but we can not do the same with the BT micro that
> will continue not working, so we would offer a half functionality... 
> 
> In that case, I think the best is trying to offer a complete solution in
> gecko to handle this properly and try to have it ready for 2.2. Bug 1091417
> - Investigate to design Bluetooth SCO connection (bluetooth voice call
> audio) API for WebRTC/VoIP/Voice Dialing use cases, could be a good starting
> point.
> 
> Jay, Bhavana, I think the best is leaving this for 2.1 and focusing in a
> complete solution for 2.2 and remove the 2.1+ flag, do you agree with it?

Maria,
I agree. It is better to have a full working solution.

Comment 15

[Maria Angeles Oteo (:oteo)]

(In reply to Jay from comment #14)
> Maria,
> I agree. It is better to have a full working solution.

Thanks a lot for your answer, let's remove the nomination

Comment 17

[Ben Tian (inactive)]

Set 2.2? per bug 1157837 comment 3.

Comment 18

[Diego Wilson [:diego]]

It seems this won't make it to v2.2 after all.

Comment 19

[BMO Automation]

Firefox OS is not being worked on