860570 - [Bluetooth] Can’t resume call after hold it by Carkit

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect, P2)

Description

[leo.bugzilla.gecko]

GENERAL Defect Description 
1. Title : [BT/ BT CAR KIT] Can’t resume call after hold it by CK
2. Precondition : PSA RT6 CK used.
3. Tester's Action : Hold call by CK
4. Detailed Symptom (ENG.) : Try to resume it by CK
5. Detailed Symptom (KOR.) : 
6. Expected : "put call on hold" option on CK should change to "resume call" but it didn't
On each other phones this option changed and user can resume the call.
7.Reproducibility: Y
1)Frequency Rate : 100%

Comment 1

[leo.bugzilla.gecko]

Attachment: cant unhold call -RT6

Dear Mozilla Team,

I upload the air log.
Please check it.

Thanks.

Comment 2

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

What's PSA RT6 CK?

Comment 3

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

Hi, from the sniffer log, it looks like very old version of gecko.
There are many 3 ways calling bug fixed (more than 6 important fix) in the latest b2g18 v.1.1
Please use the latest Gecko b2g18 version for verification.

100	Master	6	..+BRSF: 33..			Retrieved AG Supported Features

Comment 4

[leo.bugzilla.gecko]

Dear Mozilla Team,

PSA RT6 seems to be a Citroen car kit.
I'll try to test again with newer version of Gecko Bluetooth.
And update the result ASAP.

Thanks.

Comment 5

[Dylan Oliver [:doliver]]

This issue was identified as a Leo QE1 blocker. Nominating for leo?

Comment 6

[leo.bugzilla.gecko]

Dear Mozilla Team,

In air log, this carkit send to CHLD=2 to phone.
Then phone is in hold state, and unhold click from carkit.
At this time carkit send to CHLD=2 to phone again, but phone cannot handle this command. (See Frame# 260 of attached air log)

We cannot reproduce this bug because we don't have this carkit.
Please check this point.

Thanks.

Comment 7

[leo.bugzilla.gecko]

Attachment: bug movie for cant unhold call -RT6

Please check this

Comment 8

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

I confirmed this bug is valid. Thanks for reporting.

Comment 9

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

This problem is related dialer. When we received AT command CHLD=2, dialer invoke holdAndAnswer(), however, if remote side send CHLD=2 to cancel call on hold. holdAndAnswer does not fulfill.

Comment 10

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

Etienne, as we discussed face to face. We need to swap active/hold call if total number of call is 1. Please let me know if this function raises any concern for bluetooth handsfree.

Comment 11

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

Attachment: Handle call swap when CHLD=2

Comment 12

[Etienne Segonzac (:etienne)]

Comment on attachment 738960 [details] [diff] [review]
Handle call swap when CHLD=2

That sounds about right, let me ping UX for info.

Comment 13

[Etienne Segonzac (:etienne)]

The UX issue brought up this bug is the following:

The BT specs mandates the ability to hold/resume a call _also_ when there is only 1 call.
It's pretty easy to implement since we have all the platform support needed.

*But* if you put the call on hold and then stop using bluetooth you're not able to resume the call (the single call UI doesn't have hold/resume buttons right now).

Can we extend the concept we have for switching between calls in conference mode and let the user hold/resume a single call by taping the name/phone number zone?

Comment 14

[jachen]

Hey Rob- can you take a look since you were on Dialer before Ayman took over? They need help asap.

Thanks!
Jaime

Comment 15

[Rob MacDonald [:robmac]]

(In reply to Etienne Segonzac (:etienne) from comment #13)
> 
> *But* if you put the call on hold and then stop using bluetooth you're not
> able to resume the call (the single call UI doesn't have hold/resume buttons
> right now).
> 
> Can we extend the concept we have for switching between calls in conference
> mode and let the user hold/resume a single call by taping the name/phone
> number zone?

Hi Etienne...

I think this works assuming the "on hold" icon appears on the active call screen to indicate to the user that the call is indeed on hold.

I'll leave the needsinfo for Ayman in the event he has additional feedback.

- Rob

Comment 16

[Etienne Segonzac (:etienne)]

Well the needinfo is 10+ days old and this must be fixed this week, so I'll go with this 

> extend the concept we have for switching between calls in conference mode and let the user hold/resume a single call by taping the name/phone number zone

Since it does not involve new UX/visuals.

Comment 17

[Etienne Segonzac (:etienne)]

Attachment: Patch proposal

Here is a clean patch implementing hold/resume support for 1 single call and binding it to the correct Bluetooth command.

Shawn, can you confirm it fixes the bug before I ask for a formal review? Thanks!

Comment 18

[Etienne Segonzac (:etienne)]

Comment on attachment 743128 [details] [diff] [review]
Patch proposal

Let's start the review process.

Comment 19

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

Comment on attachment 743128 [details] [diff] [review]
Patch proposal

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

Etienne, it looks great to me. Sorry for late reply.

Comment 20

[Etienne Segonzac (:etienne)]

Pinging German since this was due for yesterday.

Comment 21

[Germán Toro del Valle (:gtorodelvalle)]

Comment on attachment 743128 [details] [diff] [review]
Patch proposal

Hi guys! On the paper, it looks good to me but I do not feel confortable setting the r+ without actually being able to really test the patch since I do not have the needed Bluetooth equipment at hand :-( So, if you consider it appropriate, please add an additional reviewer to really test it. If not, it will be on Etienne and myself ;-) Thanks!

Comment 22

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

I have run test case from Bluetooth side. Also, if leo confirm that will be better.

Comment 23

[Etienne Segonzac (:etienne)]

(In reply to Shawn Huang from comment #22)
> I have run test case from Bluetooth side. Also, if leo confirm that will be
> better.

Sounds good, in the meantime feel free to nit pick about the code German :)

Comment 24

[leo.bugzilla.gecko]

Dear Mozilla Team,

Our tester confirm it fixed and this case is closed.

Thanks.

Comment 25

[Dylan Oliver [:doliver]]

Looks like things are in good shape here. Can this be landed and resolved?

Comment 26

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/340201b4b7352205dedb00463253de527e2c479a

Comment 27

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 340201b4b7352205dedb00463253de527e2c479a to:
v1-train: 6ffd5a675fed78bc27cc4c2bd15af1808477126b
v1.0.1: 2f173e818735b8aa930aa9711d6706a90be2f8c2

Comment 28

[Mila Davydova]

Unable to test this issue. Don't have a bluetooth car kit.
Marking as QARegressExclude