Closed Bug 869296 Opened 7 years ago Closed 7 years ago

[Bluetooth][Certification]BT needs to know call history is empty when performing last number redial

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

x86_64
Linux
defect
Not set

Tracking

(blocking-b2g:tef+, firefox21 wontfix, firefox22 wontfix, firefox23 fixed, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

RESOLVED FIXED
1.0.1 IOT1 (10may)
blocking-b2g tef+
Tracking Status
firefox21 --- wontfix
firefox22 --- wontfix
firefox23 --- fixed
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed

People

(Reporter: shawnjohnjr, Assigned: echou)

References

Details

(Whiteboard: [status: landed, also fixes bug 860663][fixed-in-birch] QARegressExclude)

Attachments

(4 files)

Problem as the same as Bug 860726.
Bluetooth needs to know call history state is empty or not.
The purpose is to verify that phone can respond with an error message when
handsfree requests that the AG place an outgoing call corresponding to the last number
dialed on the phone.
Hey Etienne,
Is there any easy way to know whether call history is empty? From gecko bluetooth needs to the state of call history (we currently just need to know call history is empty or not).
Flags: needinfo?(etienne)
Well this is tricky since the call log is just an in-app indexedDB, and the Dialer app doesn't really have a way to message back to gecko.

One of the least horrible stuff that comes to mind would be for the platform to observe the calls array on the telephony API in order to witness that even if the re-dial command was sent no call was added.
Flags: needinfo?(etienne)
May I know if this is a must to pass Bluetooth certification? 
If this is a Bluetooth certification blocker, it should be marked as tef+.
blocking-b2g: --- → tef?
Flags: needinfo?(shuang)
Assignee: shuang → echou
Blocks: 860726
(In reply to khu from comment #3)
> May I know if this is a must to pass Bluetooth certification? 
> If this is a Bluetooth certification blocker, it should be marked as tef+.

Actually, once this is fixed, the tef+ bug 860726 would be fixed. Therefore I mark this one blocking 860726, and please make this tef+ as well.
According to HFP spec, when we receive AT command 'AT+BLDN', we shall respond with:
    
  1. 'OK' if the call history is not empty. An outgoing call would be made
  2. 'ERROR' if the call history is empty. No call would be made.
    
However, with current implementation, we are unable to know whether the call history is empty or not in Gecko. Therefore I introduce a solution, using a task and a flag to decide if a call is made after AT+BLDN is received, which may not be perfect but reliable, easy to understand and easy to implement.
Attachment #746904 - Flags: review?(gyeh)
blocking-b2g: tef? → tef+
After this patch applied, Bug 860663 will also be fixed.
Flags: needinfo?(shuang)
This blocks bug 860663 which is slated for the IOT1 milestone so I'm setting this here, too.
Target Milestone: --- → 1.0.1 IOT1 (10may)
Whiteboard: [status: patch up for review, will also fix bug 860663]
Comment on attachment 746903 [details] [diff] [review]
patch 1: v1: Do 'Last Number Redial' when we receive ATD>n

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

Clear comments. Good job!
Attachment #746903 - Flags: review?(gyeh) → review+
Comment on attachment 746904 [details] [diff] [review]
patch 2: v1: New mechanism to deal with AT commands 'AT+BLDN' and 'ATD>n'

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

r+ with question answered.

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +273,5 @@
> +{
> +public:
> +  RespondToBLDNTask() { /* Do nothing */ }
> +
> +private:

Question: Why should we put this function in private section?
Attachment #746904 - Flags: review?(gyeh) → review+
(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #10)
> Comment on attachment 746904 [details] [diff] [review]
> patch 2: v1: New mechanism to deal with AT commands 'AT+BLDN' and 'ATD>n'
> 
> Review of attachment 746904 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r+ with question answered.
> 
> ::: dom/bluetooth/BluetoothHfpManager.cpp
> @@ +273,5 @@
> > +{
> > +public:
> > +  RespondToBLDNTask() { /* Do nothing */ }
> > +
> > +private:
> 
> Question: Why should we put this function in private section?

You're right. We don't even need to implement our own ctor.
Whiteboard: [status: patch up for review, will also fix bug 860663] → [status: patch up for review, will also fix bug 860663][fixed-in-birch]
* patch for b2g18
* patch for b2g18_v1_0_1
https://hg.mozilla.org/mozilla-central/rev/d6f834c17b4f
https://hg.mozilla.org/mozilla-central/rev/fc355030e54c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [status: patch up for review, will also fix bug 860663][fixed-in-birch] → [status: landed, also fixes bug 860663][fixed-in-birch]
(In reply to Ryan VanderMeulen [:RyanVM] from comment #17)
> And to fix the typo from the b2g18 patches so that they actually compile...
> https://hg.mozilla.org/releases/mozilla-b2g18/rev/60206e032f82
> https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/588d455244ba

Thanks, Ryan. :)
Unable to verify. Lack of resources. Need Bluetooth PTS tool to verify.
Marking as QARegressExclude.
Whiteboard: [status: landed, also fixes bug 860663][fixed-in-birch] → [status: landed, also fixes bug 860663][fixed-in-birch] QARegressExclude
You need to log in before you can comment on or make changes to this bug.