Closed Bug 827266 Opened 12 years ago Closed 11 years ago

[Bluetooth][Hfp] Support feature: call waiting notification activation (AT+CCWA)

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

(3 files, 4 obsolete files)

To support "Call Waiting Notification Activation", we need to be able to handle AT command: AT+CCWA, and send call waiting notification when there's an incoming call during a call.

Please see 4.21 "Call Waiting Notification Activation" of HFP 1.5 for more detail.
Assignee: nobody → gyeh
Attachment #698612 - Flags: review?(echou)
Attachment #698612 - Attachment is obsolete: true
Attachment #698612 - Flags: review?(echou)
Attachment #698614 - Flags: review?(echou)
Comment on attachment 698614 [details] [diff] [review]
Patch 1(v1): Support feature 'call waiting notification activation'

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

ok, r=me with nits addressed and questions answered

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +732,5 @@
>        message += "\",";
>        message.AppendInt(TOA_UNKNOWN);
>        message += ",,4";
>        SendLine(message.get());
> +  } else if (msg.Find("AT+CCWA") != -1) {

Should be | msg.Find("AT+CCWA=") |, or ParseAtCommand() below will start parsing from '=', which is wrong.

@@ +927,5 @@
> +        if (mCCWA) {
> +          nsAutoCString resultCode("+CCWA: \"");
> +          resultCode += aNumber;
> +          resultCode += "\",";
> +          resultCode.AppendInt(mCurrentCallArray[aCallIndex].type);

Question: mCurrentCallArray is not found in current m-c, do you mean mCurrentCallStateArray? Or the name would change in another patch?

@@ +949,5 @@
>          }
> +
> +        MessageLoop::current()->PostTask(FROM_HERE,
> +          new SendRingIndicatorTask(number,
> +                                    mCurrentCallArray[aCallIndex].type));

Question: mCurrentCallArray is not found in current m-c, do you mean mCurrentCallStateArray? Or the name would change in another patch?
Attachment #698614 - Flags: review?(echou) → review+
Depends on: 827212
Comment on attachment 698614 [details] [diff] [review]
Patch 1(v1): Support feature 'call waiting notification activation'

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

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +927,5 @@
> +        if (mCCWA) {
> +          nsAutoCString resultCode("+CCWA: \"");
> +          resultCode += aNumber;
> +          resultCode += "\",";
> +          resultCode.AppendInt(mCurrentCallArray[aCallIndex].type);

mCurrentCallArray is defined in bug827212, patch 1. Please see that for more details. Thanks.
https://hg.mozilla.org/mozilla-central/rev/e3c728cb2119
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Please nominated for uplift approval with a risk assessment.
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 which is neccesary for certification
Testing completed: mozilla-central
Risk to taking this patch (and alternatives if risky): Fairly low. The only thing done in this patch is parsing an AT command and keeping the value as a member variable.
String or UUID changes made by this patch: no
Attachment #729424 - Flags: approval-mozilla-b2g18?
Comment on attachment 729424 [details] [diff] [review]
patch 1: for b2g18, r=echou

Approving low risk HFB patches to bring us closer to spec.
Attachment #729424 - Flags: approval-mozilla-b2g18? → approval-mozilla-b2g18+
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.
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+
Attached patch b2g18_v1_0_1 patch (obsolete) — Splinter Review
v1.0.1 patch updated.
Attachment #738770 - Attachment is obsolete: true
v1.0.1 patch updated.
Attachment #746222 - 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: