869337 - [Bluetooth][Certification]HFP PTS test TC_AG_PSI_BV_04_I test case fail

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Sean Wu]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; CIBA; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; TCO_20130507103712)

Steps to reproduce:

We did our HFP PTS test by using Boot2Gecko/Firefox OS phone.
The test case TC_AG_PSI_BV_04_I which try to verify that the AG accepts and responds to the request of the HF to query the currently selected operator name.


Actual results:

There's the Output of the PTS,please check it.Thanks.
Test case : TC_AG_PSI_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: ERROR
	- AT: ERROR
	- AT: ERROR
	- AT: post SLC command sequence complete
	- MTC: AT+COPS=3,0
	- AT: ERROR
	- FATAL ERROR (MTC): Unexpected ERROR
	- AT: Service Level Connection disabled
	- MTC: Test case ended
Final Verdict : Inconclusive


Expected results:

We want to make this PTS case pass.

Comment 1

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

Mark this bug 827230 as duplicated. This will be uplift to v.1.0.1.

Comment 2

[Sean Wu]

When I use the v1.0.1 to test TC_AG_PSI_BV_04_I, the test case still failed.
The PTS show the error information as below.
Could you please help us to check it?
Thanks very much.

Test case : TC_AG_PSI_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
	- MTC: AT+COPS=3,0
	- MTC: AT+COPS?
	- AT: AG reports the network operator: "China Mobile"
	- FATAL ERROR (MTC): Sending AT command from MTC to AT PTC timed out
	- FATAL ERROR (AT): The response to the following AT command has timed out: AT+COPS?
	- AT: SPP disconnect succeeded
	- MTC received unexpected EXIT message from AT component
Final Verdict : Inconclusive

Comment 3

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

I checked Bug 827230, missed reply OK after "OK". This is why in the original bug, it stucked at AT+COPS=3, 0 but now, it stucked at AT+COPS?.

Comment 4

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

Attachment: Patch 1: v1-Bug 869337: Fix missing At comman reply OK after +COPS

Low risk one line fix, but important to bt cert.

Comment 5

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

Let me check spec later and come back to review.

Comment 6

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

Comment on attachment 747397 [details] [diff] [review]
Patch 1: v1-Bug 869337: Fix missing At comman reply OK after +COPS

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

This is interesting. In HFP spec 1.5, there is no response 'OK' in the MSC (figure 4.7). Although I felt weird, I still followed the spec and told Gina not to return 'OK' in bug 827230 comment 7. And, in HFP spec 1.6, 'OK' has been added.

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +745,4 @@
>      message.Append(NS_ConvertUTF16toUTF8(mOperatorName));
>      message.AppendLiteral("\"");
>      SendLine(message.get());
> +    goto respond_with_ok;

Actually, we don't even need this. Remove the 'return' statement should be fine.

Comment 7

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

Well...after PTS version 4.5.3, project type HFP 1.5 and 1.6  merges into only one HFP project.
So HFP test cases now with 1.5 and 1.6 (Wideband speech related AT commands) are mixed into same project.
Maybe this can be explained and I believe spec HFP 1.5 COPS section query diagram is unclear. I'm trying to find any errata but fail.

Comment 8

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

Shawn, thanks for your information.

As Eric said, we skip send "OK" by |return| in bug 827230.

However, since HFP test cases of version 1.5 and version 1.6 are mixed together, and the test result also shows that we have to send "OK" after receiving "AT+COPS?". I think we should fix it.

Comment 9

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

Comment on attachment 747397 [details] [diff] [review]
Patch 1: v1-Bug 869337: Fix missing At comman reply OK after +COPS

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

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +745,4 @@
>      message.Append(NS_ConvertUTF16toUTF8(mOperatorName));
>      message.AppendLiteral("\"");
>      SendLine(message.get());
> +    goto respond_with_ok;

Agree :)

Comment 10

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

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #8)
> Shawn, thanks for your information.
> 
> As Eric said, we skip send "OK" by |return| in bug 827230.
> 
> However, since HFP test cases of version 1.5 and version 1.6 are mixed
> together, and the test result also shows that we have to send "OK" after
> receiving "AT+COPS?". I think we should fix it.

Let's fix it. This is a known issue of HFP spec 1.5 and fixed in version 1.6.

Reference: https://www.bluetooth.org/errata/errata_view.cfm?errata_id=1989 (login-required)

Comment 11

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

birch:  https://hg.mozilla.org/projects/birch/rev/b1c6b87e6e5b

Comment 12

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

Hi Daniel, 

This is also a certification blocker. Please mark this as tef+ as well.

Thank you.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b1c6b87e6e5b

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/974d0cad30c0
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/5fef11341a6c

Comment 15

[Mila Davydova]

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