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

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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.

Comment 1

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

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).

Comment 2

[Etienne Segonzac (: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.

Comment 3

[Kai-Chih Hu [:khu]]

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+.

Comment 4

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

(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.

Comment 5

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

Attachment: patch 1: v1: Do 'Last Number Redial' when we receive ATD>n

Comment 6

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

Attachment: patch 2: v1: New mechanism to deal with AT commands 'AT+BLDN' and 'ATD>n'

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.

Comment 7

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

After this patch applied, Bug 860663 will also be fixed.

Comment 8

[Andrew Overholt [:overholt]]

This blocks bug 860663 which is slated for the IOT1 milestone so I'm setting this here, too.

Comment 9

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

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!

Comment 10

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

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?

Comment 11

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

(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.

Comment 12

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

fixed in birch:

https://hg.mozilla.org/projects/birch/rev/fc355030e54c
https://hg.mozilla.org/projects/birch/rev/d6f834c17b4f

Comment 13

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

Attachment: patch 2: for b2g18

* patch for b2g18

Comment 14

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

Attachment: patch 2: for v1_0_1

* patch for b2g18_v1_0_1

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d6f834c17b4f
https://hg.mozilla.org/mozilla-central/rev/fc355030e54c

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/7201d74ad0bc
https://hg.mozilla.org/releases/mozilla-b2g18/rev/d4d07bfa855e

https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/a803b9922fbe
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/2a004d4926f2

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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

Comment 18

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

(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. :)

Comment 19

[Mila Davydova]

Unable to verify. Lack of resources. Need Bluetooth PTS tool to verify.
Marking as QARegressExclude.