902371 - B2G RIL: Expose current device technology (GSM or CDMA).

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Edgar Chen [:edgar]]

Some designs are quite different between GSM and CDMA, like network selection [1], emergency call [2], call waiting [3] ... etc. Gaia needs to show different page or run into different logic based on the different technology. It will be good if RIL can provide the information of underlying technology to Gaia in run time, especially for multi-tech device.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=899484
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=881863
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=822210

Comment 1

[Edgar Chen [:edgar]]

Some gecko components (e.g., bluetooth) needs this kinds information as well. Please see bug 912019 comment #0.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

So this bug is focusing on exposing API to Gaia, and bug 912019 is about *internal* API?

Comment 3

[Edgar Chen [:edgar]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #2)
> So this bug is focusing on exposing API to Gaia, and bug 912019 is about
> *internal* API?

Yes

Comment 4

[Edgar Chen [:edgar]]

I think mozMobileConnection is the suitable place to put this API. Any other suggestion? :)

Comment 5

[Ken Chang[:kenkai]]

(In reply to Edgar Chen [:edgar][:echen] from comment #4)
> I think mozMobileConnection is the suitable place to put this API. Any other
> suggestion? :)
I wonder if we really need a new API. Should we reuse voicechange/datachange?

Comment 6

[Preeti Raghunath(:Preeti)]

Moving to 1.3 as it is a feature request. 905081 has been moved to 1.3

Comment 7

[Edgar Chen [:edgar]]

As mention in bug 905081 comment #9, gaia will use build time configuration file for no sim inserted case. So this bug no longer block bug 905081.

Comment 8

[Kai-Chih Hu [:khu]]

Triaged and tried to push to 1.4. 
Removed target milestone.

Comment 9

[Edgar Chen [:edgar]]

(In reply to Ken Chang from comment #5)
> (In reply to Edgar Chen [:edgar][:echen] from comment #4)
> > I think mozMobileConnection is the suitable place to put this API. Any other
> > suggestion? :)
> I wonder if we really need a new API. Should we reuse voicechange/datachange?

Currently, the mozMobileConneciton.{voice|data}.type [1] will be null if device is not registered to a network. Do you mean we should reuse this?
For example, if device is NOT registered to a network, mozMobileConneciton.{voice|data}.type will be the underlying radio technology of modem, instead of null.
I afraid this may confuse the API user.

My original idea is add a new attribute in mozMobileConneciton, something like |radioTechnology|, and the possible value is "cdma" or "gsm".
How do you think? :)

[1] http://dxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMMobileConnection.idl?from=nsIDOMMobileConnection.idl#473

Comment 10

[Edgar Chen [:edgar]]

We need to consider LTE as well.

Comment 11

[Ken Chang[:kenkai]]

This is a 1.4+ bug.

Comment 13

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Edgar Chen [:edgar][:echen] from comment #9)
> (In reply to Ken Chang from comment #5)
> > (In reply to Edgar Chen [:edgar][:echen] from comment #4)
> > > I think mozMobileConnection is the suitable place to put this API. Any other
> > > suggestion? :)
> > I wonder if we really need a new API. Should we reuse voicechange/datachange?
> 
> Currently, the mozMobileConneciton.{voice|data}.type [1] will be null if
> device is not registered to a network. Do you mean we should reuse this?
> For example, if device is NOT registered to a network,
> mozMobileConneciton.{voice|data}.type will be the underlying radio
> technology of modem, instead of null.
> I afraid this may confuse the API user.
> 
> My original idea is add a new attribute in mozMobileConneciton, something
> like |radioTechnology|, and the possible value is "cdma" or "gsm".
> How do you think? :)
> 

We already expose 'supportedNetworkTypes' on bug 952043. So is this a duplicate? Please let me know if I misunderstand the scope of this bug.

> [1]
> http://dxr.mozilla.org/mozilla-central/source/dom/network/interfaces/
> nsIDOMMobileConnection.idl?from=nsIDOMMobileConnection.idl#473

Comment 14

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

remove 1.4+ flag as this is a feature.
Needinfo to Edgar for Hsinyi's question.

Comment 15

[Edgar Chen [:edgar]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #13)
> We already expose 'supportedNetworkTypes' on bug 952043. So is this a
> duplicate? Please let me know if I misunderstand the scope of this bug.
Bug 952026 can covered by bug 952043.

But unfortunately, this bug cannot be covered by 'supportedNetworkTypes' for some cases, especially in world phone. :(

'supportedNetworkTypes' only provides the information of device's capability.
Takes world phone as an example, it can run as GSM phone or CDMA phone depends on user configuration, so the 'supportedNetworkType' will return ['gsm', 'wcdma', 'cdma', 'evdo']. In such case, API user only knows this is a world phone, but still unable to know device is in GSM mode or CDMA mode.

The only usage that I can imagine is settings app may want to show different menu for GSM/CDMA dynamically. But it seems there is no such requirement for now. I guess we don't need to worry about this bug until someone starts needing it.

Thank you.

Comment 16

[Ben Tian (inactive)]

(In reply to Edgar Chen [:edgar][:echen] from comment #15)
> The only usage that I can imagine is settings app may want to show different
> menu for GSM/CDMA dynamically. But it seems there is no such requirement for
> now. I guess we don't need to worry about this bug until someone starts
> needing it.
Here someone comes. Bluetooth needs this API to know whether GSM/CDMA is in use, and handle call state changes accordingly.

Comment 17

[Anshul]

Gecko already notifies gaia what radio tech the device is registered on. Can BT not use the API mozConnection.voice.type?

Comment 18

[Ben Tian (inactive)]

(In reply to Anshul from comment #17)
> Gecko already notifies gaia what radio tech the device is registered on. Can
> BT not use the API mozConnection.voice.type?
Do you mean [1]? [1] provides only implicit info about whether GSM/CDMA is in use and bluetooth has to parse the strings in a messy way as [2]. What we expect is an API to get current radio tech directly. Please refer to bug 912019 comment #0 for more info.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/mobileconnection/interfaces/nsIDOMMobileConnection.idl#509
[2] http://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluez/BluetoothHfpManager.cpp#1549

Comment 19

[Arthur Chen [:arthurcc][inactive after 6/30]]

We use similar logic in gaia to determine the category of the network types. Is there any strong reason to request a new API?

Comment 20

[Edgar Chen [:edgar]]

(In reply to Arthur Chen [:arthurcc] from comment #19)
> We use similar logic in gaia to determine the category of the network types.
> Is there any strong reason to request a new API?

As I know, setting will use 'supportedNetworkTypes' [1] to determine the category of the network types. Please let me know if I am misunderstand anything, thank you.

[2] Please see bug 952043.

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

(In reply to Edgar Chen [:edgar][:echen] from comment #20)
> (In reply to Arthur Chen [:arthurcc] from comment #19)
> > We use similar logic in gaia to determine the category of the network types.
> > Is there any strong reason to request a new API?
> 
> As I know, setting will use 'supportedNetworkTypes' [1] to determine the
> category of the network types. Please let me know if I am misunderstand
> anything, thank you.
> 
> [2] Please see bug 952043.

supportedNetworkTypes is used to determined the supported types. But I think what Ben want is the current connecting type in used. To me mozConnection.voice.type is sufficient for similar use cases in gaia as Ben wants.

Comment 22

[Edgar Chen [:edgar]]

(In reply to Ben Tian [:btian] from comment #18)
> (In reply to Anshul from comment #17)
> > Gecko already notifies gaia what radio tech the device is registered on. Can
> > BT not use the API mozConnection.voice.type?
> Do you mean [1]? [1] provides only implicit info about whether GSM/CDMA is
> in use and bluetooth has to parse the strings in a messy way as [2]. What we
> expect is an API to get current radio tech directly. Please refer to bug
> 912019 comment #0 for more info.
> 
> [1]
> http://dxr.mozilla.org/mozilla-central/source/dom/mobileconnection/
> interfaces/nsIDOMMobileConnection.idl#509
> [2]
> http://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluez/
> BluetoothHfpManager.cpp#1549

(((offline discuss with Ben)))
RIL have a plan to handle call state for both CDMA and GSM in RIL side. After that BT can handle CDMA call and GSM call in a unified way and no longer need to worry about 'network type'.

Comment 23

[Edgar Chen [:edgar]]

Gecko already provide mozConnection.voice.type to indicate the radio tech that device is registered on. The purpose of this bug is to expose the radio tech even if device is NOT registered to network. But it seems no one needs this for now, so close it. Please re-open if someone starts needing this.

Thank you.