828882 - [Bluetooth][Certification]HFP PTS test case TC_AG_TCA_BV_04_I failed due to one ATD after CHUP was been ignored

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Bluetooth, defect)

Description

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

The test performed via make an outgoing call first then hang up the call.
However, the call was not been canceled.

TC_AG_TCA_BV_04_I
Test case : TC_AG_TCA_BV_04_I started
	- SDP Service record for PTS: 'Handsfree HF' successfully registered
	- The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, 
	- AT: SPP connect succeeded
	- AT: Service Level Connection established
	- AT: post SLC command sequence complete
	- HCI: Audio Connection enabled
	- FATAL ERROR (AT): The response to the following AT command has timed out: AT+CHUP
	- MTC received unexpected EXIT message from AT component
	- HCI: Audio Connection disabled
	- AT: SPP disconnect succeeded
	- MTC: Test case ended
Final Verdict : Inconclusive

	4,834	Slave	46	ATD0988095164;.	Dial: 0988095164			27	 00:00:01.856000	2013/1/10 下午 06:01:03.999000	
	4,836	Master	46	..OK..			Dialed Successfully	18	 00:00:00.078000	2013/1/10 下午 06:01:04.077000	
	4,837	Master	46	..+CIEV: 4,2..		Call Setup indicator's status report		26	 00:00:00.125000	2013/1/10 下午 06:01:04.202000	
	4,840	Slave	46	AT+CHUP.	Terminate the call			20	 00:00:00.031000	2013/1/10 下午 06:01:04.233000	
	4,845	Master	46	..OK..			Success	18	 00:00:00.078000	2013/1/10 下午 06:01:04.311000	
	4,893	Master	46	..+CIEV: 6,4..		Signal indicator's status report		26	 00:00:02.231000	2013/1/10 下午 06:01:06.542000

Comment 1

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

The problem here is an outgoing call was made and soon Bluetooth certification machine sent AT+CHUP which tries to cancel outgoing call.
It seems if the call does not enter into CALL_CONNECTED state, AT+CHUP command will be ignored.
This leads call hang-up failure.
This also related to dialer like Bug 857795, which required to fix in gaia side.

Comment 2

[Wayne Chang [:wchang]]

Triage 4/12 - Leo+ for certification

Comment 3

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

It looks like dialer indeed call "telephony.active.hangUp()", but somehow under telephony ignore hangUp operation. I need to check what happened in Telephony and RIL. It looks like nothing related to dialer now.

Comment 4

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

Attachment: logcat

Comment 5

[Ken Chang[:kenkai]]

The first call status was changed at 12:08:14.861.
=>04-15 12:08:14.861 I/Gecko   (  790): -*- RadioInterfaceLayer: Received message from worker: {"rilMessageType":"callStateChange","call":{"state":2,"callIndex":1,"toa":129,"isMpty":false,"isMT":false,"als":0,"isVoice":true,"isVoicePrivacy":false,"number":"0988095164","numberPresentation":0,"name":"","namePresentation":0,"uusInfo":null,"direction":"outgoing"}}

And RILContentHelper didn't get any hang up command until 12:08:25.611.
=>04-15 12:08:25.611 I/GeckoDump(  921): !!!!!!!!!!!!!!!!!!ending call!!!!!!!!!!!!!
  04-15 12:08:25.611 I/Gecko   (  921): -*- RILContentHelper: Hanging up call no. 1

Because you added this log,"!!!!!!!!!!!!!!!!!!ending call!!!!!!!!!!!!!", in Gaia, it seems 
the upper layer didn't ask the end call procedure.

Comment 6

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

I found in dialer.js "sendCommandToCallScreen(type, command) ", CHUP command actually 
callScreenWindow.postMessage(message, COMMS_APP_ORIGIN), but handleCommand(evt) cannot get message.

Comment 7

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

Hi Etienne, as we talked this morning, please help to fix this bug in dialer. We need to make sure system message sent after call screen is ready.

Comment 8

[[e-mail]]

Attachment: etienne's quick wait-till-callScreenWindowLoaded patch

Help shuang to tackle down the issue, which is occurred in gaia dialer.

The root issue is sendCommandToCallScreen is called but callScreenWindow is not yet Loaded.

This patch is from etienne's quick hack. using timer to wait for callScreenWindow loaded, still needs to find a better way to resolve this bug.

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

tef? as this can also impact BT cert for TEF

Comment 10

[Etienne Segonzac (:etienne)]

Attachment: WIP

Hey Shawn, can you test this patch?

Comment 11

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

Comment on attachment 738553 [details] [diff] [review]
WIP

Hi Etienne, thanks for the patch, I tried over 30 times, I've seen twice times that CHUP was been ignore. Whenever i added extra logs, problem cannot be reproduced. Overall fail rate was dramatic decreased but i can still see problem.

Comment 12

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

This patch helps in general, at least largely reduce the fail rate.

Comment 13

[Joe Cheng [:jcheng] (please needinfo)]

back to leo+ for now until tef release partner confirms this is blocking BT cert.

Comment 14

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

Any suggestion for Comment 11?

Comment 15

[Etienne Segonzac (:etienne)]

Attachment: Patch proposal

Here is a better version of the patch, ready to ask for review.

Shawn, let me know how it works out.

Comment 16

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

Etienne, great, LGTM. I've tested over 15 times for this bug. I don't see any problem.

Comment 17

[Francisco Jordano [:arcturus] [:francisco]]

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

Great job as always :P

Just a quick question:

https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/js/dialer.js#L205

Should we use callScreenWindowReady on the sendCommandToCallScreen ? Just wondering if we have a queue of commands which one command in the middle that makes the window close, we do that, and then we continue trying sending commands.

Anyway, a situation that is taking into account in the sendCommandToCallScreen first check.

Thanks Etienne!

Comment 18

[Etienne Segonzac (:etienne)]

(In reply to Francisco Jordano [:arcturus] from comment #17)
> Comment on attachment 740792 [details] [diff] [review]
> Patch proposal
> 
> Great job as always :P
> 
> Just a quick question:
> 
> https://github.com/mozilla-b2g/gaia/blob/master/apps/communications/dialer/
> js/dialer.js#L205
> 
> Should we use callScreenWindowReady on the sendCommandToCallScreen ? Just
> wondering if we have a queue of commands which one command in the middle
> that makes the window close, we do that, and then we continue trying sending
> commands.
> 
> Anyway, a situation that is taking into account in the
> sendCommandToCallScreen first check.

Yep we're pretty safe with the current checks.
We could eventually move the queuing logic to the sendCommandToCallScreen level (as opposed to being bluetooth only) but not sure it makes sense at the moment and don't want to prematurely generalize :)

Comment 19

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/533553f72a549ab003475da64ed7666c4898a9eb

Comment 20

[Ryan VanderMeulen [:RyanVM]]

One more for you, James!

Comment 21

[James Lal [:lightsofapollo]]

forwarding back to john

Comment 22

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

v1-train 018f29d

Comment 23

[Joe Cheng [:jcheng] (please needinfo)]

tef?, this blocks tef BT cert as well

Comment 24

[Ryan VanderMeulen [:RyanVM]]

John, can you please assist with the v1.0.1 uplift?

Comment 25

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

v1.0.1 70da1f7

Comment 26

[Mila Davydova]

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