827230 - [Bluetooth][Hfp] Support feature: Query Operator Selection (AT+COPS?)

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Gina Yeh [:gyeh] [:ginayeh]]

To support "Query Operator Selection", we need to handle AT command: "AT+COPS?", and "AT+COPS=3,0" shall be sent by the HF to the AG prior to sending the AT+COPS? command.


Please see 4.8 "Query Operator Selection" of HFP 1.5 for more detail.

Comment 1

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: Patch 1(v1): Support feature 'Query Operator Selection' (AT+COPS?)

Note that values of AT+COPS command will be examined in a follow-up with the "Mobile Equipment Error" report code "+CME ERROR:".

Comment 2

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: Patch 1(v2): Support feature 'Query Operator Selection' (AT+COPS?)

Move "AT+COPS=3,0" part from Bug827255 to this patch

Comment 3

[Eric Chou [:ericchou] [:echou]]

Comment on attachment 700823 [details] [diff] [review]
Patch 1(v2): Support feature 'Query Operator Selection' (AT+COPS?)

Review of attachment 700823 [details] [diff] [review]:
-----------------------------------------------------------------

Please send me another review after questions are answered or revisions are made. Thank you.

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +567,5 @@
>  
> +  nsIDOMMozMobileNetworkInfo* network;
> +  voiceInfo->GetNetwork(&network);
> +  NS_ENSURE_TRUE(network, NS_ERROR_FAILURE);
> +  network->GetShortName(mOperatorName);

Question: According to HFP and GSM spec, the result code +COPS is composed of three arguments: <mode>,<format> and <operator>. Since the <format> argument shall be 0 in HFP, and 0 means "long format alphanumeric <operator>", I was wondering if we should call GetLongName() instead of GetShortName().

@@ +664,5 @@
> +    if (!atCommandValues[0].EqualsLiteral("3") ||
> +        !atCommandValues[1].EqualsLiteral("0")) {
> +      if (mCMEE) {
> +        SendCommand("+CME ERROR: ", BluetoothCmeError::OPERATION_NOT_SUPPORTED);
> +      }

I think we still need to respond with "ERROR" even when mCMEE is false, or it may cause an IOT issue because of no response.

@@ +668,5 @@
> +      }
> +      return;
> +    }
> +  } else if (msg.Find("AT+COPS?") != -1) {
> +    nsAutoCString message("+COPS: 0,0,\"");

Question: Is it correct to set the first argument to 0? I'm curious if the variable |networkSelectionMode| should be what we are looking for.

Comment 4

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: Patch 1(v3): Support feature 'Query Operator Selection' (AT+COPS?)

New patch with the following changes:
- Get networkSelectionMode from nsIMobileConnectionProvider. It's value could be null(unknown)/automatic/manual. The value of null(unknown) is mapped to auto since there's no appropriate value of mode could be set. I also check the implementation in Android, they use a fix value of 0 for mode.
- Reply ERROR when CMEE is not enabled and the values of AT+COPS command is wrong
- Operator name is included in the response of AT+COPS? command although it might be ignored with specific mode

Comment 5

[Eric Chou [:ericchou] [:echou]]

Comment on attachment 703730 [details] [diff] [review]
Patch 1(v3): Support feature 'Query Operator Selection' (AT+COPS?)

Review of attachment 703730 [details] [diff] [review]:
-----------------------------------------------------------------

Gina, It seems you attached a wrong patch. :|

Comment 6

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: Patch 1(v3): Support feature 'Query Operator Selection' (AT+COPS?)

Oops! Eric, I updated the attachment last Friday, but I just found something sad a few minutes ago, the attachment wasn't successfully updated somehow...

Comment 7

[Eric Chou [:ericchou] [:echou]]

Comment on attachment 704386 [details] [diff] [review]
Patch 1(v3): Support feature 'Query Operator Selection' (AT+COPS?)

Review of attachment 704386 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with nits addressed

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +725,5 @@
> +    message.AppendInt(mNetworkSelectionMode);
> +    message += ",0,\"";
> +    message += NS_ConvertUTF16toUTF8(mOperatorName);
> +    message += "\"";
> +    SendLine(message.get());

We should call |return| here otherwise "OK" would be sent.

::: dom/bluetooth/BluetoothHfpManager.h
@@ +98,5 @@
>    bool mCCWA;
>    bool mCLIP;
>    bool mCMEE;
>    bool mCMER;
> +  bool mNetworkSelectionMode;

Since mNetworkSelectionMode is used as an integer in BluetoothHfpManager.cpp, we should use |int| to declare it.

Comment 8

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: Final version, Support feature: Query Operator Selection (AT+COPS?), r=echou

try:
https://tbpl.mozilla.org/?tree=Try&rev=3a0cc1514743
https://tbpl.mozilla.org/?tree=Try&rev=aac48a5b4787

Comment 9

[Gina Yeh [:gyeh] [:ginayeh]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0118758d92c2

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0118758d92c2

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Please nominated for uplift approval with a risk assessment.

Comment 12

[Eric Chou [:ericchou] [:echou]]

Attachment: patch 1: for b2g18, r=echou

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): no
User impact if declined: would miss a Bluetooth HFP feature(AT+COPS) which is neccesary for certification
Testing completed: mozilla-central
Risk to taking this patch (and alternatives if risky): Fairly low. The stuff done in this patch only includes parsing an AT command, responding with proper response, and keeping the value as a member variable.
String or UUID changes made by this patch: no

Comment 13

[Alex Keybl [:akeybl]]

Comment on attachment 729436 [details] [diff] [review]
patch 1: for b2g18, r=echou

Approving low risk HFB patches to bring us closer to spec.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/db47de9e72db

Comment 15

[Kai-Chih Hu [:khu]]

This bug(and other 9 bugs) block Bluetooth certification. So, these bugs need to be marked as tef+ and landed to v1.0.1 in order to pass Bluetooth certification: 

bug 827255
bug 827212
bug 827266
bug 828175
bug 823346
bug 827230
bug 828798
bug 835740
bug 846647
bug 828160

So, mark these bugs as tef?. These fixes have some dependency and it would be better to have them landed in a specific order. Gina has a good view on this.

Comment 16

[Gina Yeh [:gyeh] [:ginayeh]]

I recommend to land these patches in the following order:

01. bug827204
02. bug827255
03. bug823346
04. bug827230
05. bug828798
06. bug827212, patch 1
06. bug827212, patch 2
07. bug827266
08. bug828175
09. bug846647
10. bug825861
11. bug825851
12. bug835740




I'm going to attach patches for b2g18_v1_0_1 for each bug. Please land them in the above order. There should be no conflict and feel free to let me know if I can be any help.

Comment 17

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: b2g18_v1_0_1 patch

Comment 18

[Joe Cheng [:jcheng] (please needinfo)]

tef- for now until tef release partner confirms this is blocking BT cert.

Comment 19

[Daniel Coloma:dcoloma]

Seems it is confirmed as per bug 868347

Comment 20

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: b2g18_v1_0_1 patch

v1.0.1 patch updated.

Comment 21

[Gina Yeh [:gyeh] [:ginayeh]]

Ryan, I've updated all patches. Please land them in the following order, thanks.

01. bug827204
02. bug827255
(03. bug823346 has been landed on v1.0.1)
04. bug827230
05. bug828798
06. bug827212, patch 1
06. bug827212, patch 2
07. bug827266
08. bug828175
09. bug846647
10. bug825861
11. bug825851
12. bug835740

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/1417685a2616