Closed Bug 827204 Opened 12 years ago Closed 12 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
Status: NEW → RESOLVED
Closed: 12 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) (deleted) — 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+
Attached patch b2g18_v1_0_1 patch (deleted) — Splinter Review
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.

Attachment

General

Created:
Updated:
Size: