Closed Bug 827204 Opened 9 years ago Closed 9 years ago

[Bluetooth][Hfp] Activate/Deactivate "indicator events reporting" (AT+CMER)

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla21
blocking-b2g tef+
Tracking Status
firefox20 --- wontfix
firefox21 --- fixed
b2g18 + fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: gyeh, Assigned: gyeh)

References

Details

Attachments

(2 files, 2 obsolete files)

When we receive AT command AT+CMER=0, no indicator events should be reported back to headset; when receiving AT+CMER=1, indicator events like signal and callsetup should be reported.

Please see 4.2.1 "Service Level Connection Initialization" of HFP 1.5 for more detail.
Assignee: nobody → gyeh
Attachment #698543 - Flags: review?(echou)
Comment on attachment 698543 [details] [diff] [review]
Patch 1(v1): Activate/Deactivate "indicator events reporting"

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

Looks good. r+ after the question is answered.

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +617,5 @@
>       * Do nothing but respond with "OK".
>       */
> +    ParseAtCommand(msg, 8, atCommandValues);
> +
> +    if (atCommandValues.Length() != 4) {

Question: How about checking if the length is "less and equal than 4" instead of "not equal to 4"? The spec says that AT+CMER may be longer than 4 arguments. 

The format of AT+CMER is: AT+CMER=[<mode>[,<keyp>[,<disp>[,<ind> [,<bfr>]]]]]
Attachment #698543 - Flags: review?(echou) → review+
Yes, the length checking shall be "<= 4" rather than "!= 4". Thanks.

Final patch with nits picked.

try:
https://tbpl.mozilla.org/?tree=Try&rev=084eea27bfca
https://tbpl.mozilla.org/?tree=Try&rev=5030c673f5d6
Attachment #698543 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/b2c015b94f24
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
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
bug 827204
bug 825861
bug 825851

So, mark these bugs as tef?. These fixes have some dependency and it would be better to have them landed in a specific order. I'll provide the order later.
blocking-b2g: --- → tef?
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.
Attached patch b2g18_v1_0_1 patch (obsolete) — Splinter Review
tef- for now until tef release partner confirms this is blocking BT cert.
blocking-b2g: tef? → -
Seems it is confirmed as per bug 868347
blocking-b2g: - → tef+
Updated.
Attachment #738761 - Attachment is obsolete: true
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
You need to log in before you can comment on or make changes to this bug.