1215451 - [Go-Flip][Bluetooth Certification] Some cases in HFP are FAIL

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Lingling Zhao]

Attachment: log.zip

In Bluetooth certification test , the following cases are FAIL:
TP/ECC/BI-03-I
TP/ECS/BV-01-I
TP/ECS/BV-02-I
TP/ECS/BV-03-I
TP/TCA/BV-05-I

Please help to confirm if these cases are supported in FFOS for CDMA device, if yes please help to analyze these cases.

Comment 1

[Lingling Zhao]

Response From Qualcomm as following:

Dear customer,

Please make sure your DUT supports three way call with CDMA network, even there's no BT headset.
If you DUT failed to support this feature, then you can disable them in the PICS to avoid testing these BQB cases.

FYI.
For Firefox BT issues,
Qualcomm only support the stack and firmware parts, for upper layer issues, you have to check with Mozilla community.
Actually, there's no qualified listing from Qualcomm part for Firefox platform.
You have to check with Mozilla too about this.

Comment 2

[Wesly Huang (EPM)]

Hi Shawn:

I thought we do not support CDMA for this, right? Would you help confirm? Or I shall check w/ telephony team for this?

Thank you.

Comment 3

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

(In reply to Wesly Huang (TAM) from comment #2)
> Hi Shawn:
> 
> I thought we do not support CDMA for this, right? Would you help confirm? Or
> I shall check w/ telephony team for this?
> 
> Thank you.

As far as I know, we never support CDMA network before (and no reference devices can test with). Will you provide devices for us?

Comment 4

[Wesly Huang (EPM)]

Hi Lingling,

After confirmed w/ BT team, we are considering to support CDMA network of certain BT profile in some future release, but not yet in 2.2. FYI.

Comment 5

[Lingling Zhao]

Hi,

I can see from the following code that when answer cdmaCallWaiting, SendCommand() is removed in bluedroid: 
http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1171

But it is still in bluez:
http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluez/BluetoothHfpManager.cpp#1762

So how is the removed function realized in bluedroid?

Thanks.

Comment 6

[Wesly Huang (EPM)]

Hi Shawn:

Is it possible for you to help answer Lingling's question above? Thanks.

Comment 7

[Ben Tian (inactive)]

(In reply to Lingling Zhao from comment #5)
> So how is the removed function realized in bluedroid?

We haven't done it on bluedroid for no corresponding CDMA phone requirement.

Comment 8

[Lingling Zhao]

Hi Ben,

I think sending CINDType::CALLHELD is needed when answer cdmaCallWaiting in HFP test, so I try to find a solution.

When handle callStateChanged, it will call SendCommand() or UpdateCIND() for different callState in bluez to realize some funcitons:
mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1064
But these actions are missing in bluedroid:
mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluez/BluetoothHfpManager.cpp#1468

HandleCallStateChanged() is used not only for CDMA but also for GW, and in fact these functions in bluedroid are ok in our test for GW device. so can you please tell me how are these functions realized in bluedroid? Maybe I can do the similar things.

Thanks very much!

Comment 9

[Ben Tian (inactive)]

(In reply to Lingling Zhao from comment #8)
> Hi Ben,
> 
> I think sending CINDType::CALLHELD is needed when answer cdmaCallWaiting in
> HFP test, so I try to find a solution.
> 
> When handle callStateChanged, it will call SendCommand() or UpdateCIND() for
> different callState in bluez to realize some funcitons:
> mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/
> BluetoothHfpManager.cpp#1064
> But these actions are missing in bluedroid:
> mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluez/
> BluetoothHfpManager.cpp#1468

You may use |SendLine| [1], which triggers formatted_at_response [2], to send command. However for CINDType::CALLHELD, I think bluedroid stack wraps it inside and triggers from gecko introduces inconsistent CALLHELD state. A better way is to manipulate call array to update phone CIND as GSM phones.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#869
[2] http://androidxref.com/5.1.1_r6/xref/hardware/libhardware/include/hardware/bt_hf.h#265

> HandleCallStateChanged() is used not only for CDMA but also for GW, and in
> fact these functions in bluedroid are ok in our test for GW device. so can
> you please tell me how are these functions realized in bluedroid? Maybe I
> can do the similar things.

By GW do you mean GSM phones? Please specify what "ok in our test" means.

Comment 10

[Lingling Zhao]

(In reply to Ben Tian [:btian] from comment #9)
> By GW do you mean GSM phones? Please specify what "ok in our test" means.

Yes, it is GSM phone. We test the HFP on Flame2.2, and the related cases are pass, callheld can be received in PTS tool.

Comment 11

[Lingling Zhao]

Hi Ben,

I add some code for cdma to update phone CIND according GSM.

The following code is added in the end of UpdateSecondNumber(the second call is incoming) in [1]:
  sBluetoothHfpInterface->PhoneStateChange(
      1, 0, HFP_CALL_STATE_INCOMING,
      aNumber, mCdmaSecondCall.mType,
      new PhoneStateChangeResultHandler());
and the following code is added in the end of AnswerWaitingCall(answer the second call, its state becomes to be connected, the first one becomes to be held) in [2]:
  //For waiting call
  sBluetoothHfpInterface->PhoneStateChange(
     1, 1, HFP_CALL_STATE_IDLE,
     mCdmaSecondCall.mNumber, mCdmaSecondCall.mType,
     new PhoneStateChangeResultHandler());
  //For held call
  sBluetoothHfpInterface->PhoneStateChange(
     1, 1, HFP_CALL_STATE_IDLE,
     mCurrentCallArray[1].mNumber, mCurrentCallArray[1].mType,
     new PhoneStateChangeResultHandler());

In the new test, one of the FAIL cases TP/ECS/BV-03-I is pass, that means it can send command and update state to the bluetooth test tool
.
But the other ones TP/ECS/BV-01-I and TP/ECS/BV-02-I are still FAIL. The fail reason updates to:
 "- FATAL ERROR (AT): var_twc.held_calls = 0, but the curent call list indicates at least one call is held" and "AG IUT does not report (callheld=1) (does not report that there is both a held and active call)."
It looks like that it still doesnot report (callheld =1) although I have add 1(held number)  in AnswerWaitingCall.

Can you give me some suggestions?

[1]http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1147
[2]http://mxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1160

Thanks.

Comment 12

[Ben Tian (inactive)]

(In reply to Lingling Zhao from comment #11)
> But the other ones TP/ECS/BV-01-I and TP/ECS/BV-02-I are still FAIL. The
> fail reason updates to:
>  "- FATAL ERROR (AT): var_twc.held_calls = 0, but the curent call list
> indicates at least one call is held" and "AG IUT does not report
> (callheld=1) (does not report that there is both a held and active call)."
> It looks like that it still doesnot report (callheld =1) although I have add
> 1(held number)  in AnswerWaitingCall.

Did you either 1) update calls array or 2) revise cind response [1] to reflect callheld state during SLC connection establishment? You can also trace [2] to confirm whether bluedroid sends out callheld CIEV or not.

[1] https://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1718
[2] http://androidxref.com/5.1.0_r1/xref/external/bluetooth/bluedroid/btif/src/btif_hf.c#1170

Provide the failed trace of TP/ECS/BV-01-I and TP/ECS/BV-02-I so we can give you more advise.

Comment 13

[Lingling Zhao]

Hi Ben,

I attached the log. You can find the logcat and PTS log.

I can see the log in TP/ECS/BV-01-I and TP/ECS/BV-02-I:
 D/bt-btif (  261): phone_state_change: idx = -1
 W/bt-btif (  261): BTHF: btif_hf_check_if_slc_connected: No SLC connection up
but in TP/ECS/BV-03-I, the log is valid. 

"Did you either 1) update calls array or 2) revise cind response [1] to reflect callheld state during SLC connection establishment?"
1) I doesnot add the cdmawaiting call into the calls array, but I note it and include it when PhoneStateChange.
2) I donot know whether CindNotification() will be called or not because I cannot find the place where it is called, but I add the code to revise cind response in it. I will tell you the result later after the test.

Comment 14

[Lingling Zhao]

Attachment: ECS03 OK version.zip

Comment 15

[Lingling Zhao]

Hi Ben,

For 2), I till waiting for the test result from my validation colleague...

In case TP/ECS/BV-01-I and TP/ECS/BV-02-I, after the incoming call is answered, HandleCallStateChanged is called, so I modify the code in [1] to confirm the right phoneStateChange is called:
  if (!mCdmaSecondCall.mNumber.IsEmpty() && (numActive == 1)) {
    //for the first call
    sBluetoothHfpInterface->PhoneStateChange(
      1, 1, callSetupState,
      mCurrentCallArray[aCallIndex].mNumber, type,
      new PhoneStateChangeResultHandler());
    //for the second call
    sBluetoothHfpInterface->PhoneStateChange(
          1, 1, callSetupState,
          mCdmaSecondCall.mNumber, type,
          new PhoneStateChangeResultHandler());
  } else {
  sBluetoothHfpInterface->PhoneStateChange(
    numActive, numHeld, callSetupState,
    mCurrentCallArray[aCallIndex].mNumber, type,
    new PhoneStateChangeResultHandler());
  }

But the case is still FAIL. The test result updates to "FATAL ERROR (AT): +CIEV(callheld=1) received when there is no second call process". I think this maybe because there is no SCL in the beginning, so no second call process is updated in [2]. But the same case is pass in GMS devices.

[1]https://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#935
[2] http://androidxref.com/5.1.0_r1/xref/external/bluetooth/bluedroid/btif/src/btif_hf.c#1170

Comment 16

[Ben Tian (inactive)]

(In reply to Lingling Zhao from comment #15)
> +CIEV(callheld=1) received when there is no second call process". I think
> this maybe because there is no SCL in the beginning, so no second call
> process is updated in [2]. But the same case is pass in GMS devices.

|UpdatePhoneCIND| is not called if SLC has not established [1], so you need to remember the second call for CIND response (as mentioned in comment 13), in order to make AG respond correct CIND status in [2] during SLC establishment.

[1] https://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1087
[2] https://dxr.mozilla.org/mozilla-central/source/dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp#1718

Comment 17

[Ben Tian (inactive)]

(In reply to Lingling Zhao from comment #13)
> 2) I donot know whether CindNotification() will be called or not because I
> cannot find the place where it is called, but I add the code to revise cind
> response in it. I will tell you the result later after the test.

CIND response is required during SLC establishment for HS to query current CIND status. Please refer to section 4.2, HFP spec 1.6.
"Once the HF has the necessary supported indicator and ordering information, it shall retrieve the current status of the indicators in the AG using the AT+CIND? Read command."

Comment 18

[Lingling Zhao]

Yes, it works. My validation colleague just tells me that TP/ECS/BV-01-I and TP/ECS/BV-02-I are pass after I add the code in 2) in comment 13.

Thanks very much.

Comment 19

[Will Wang [:WillWang]]

(In reply to Lingling Zhao from comment #11)
> But the other ones TP/ECS/BV-01-I and TP/ECS/BV-02-I are still FAIL. The
> fail reason updates to:
>  "- FATAL ERROR (AT): var_twc.held_calls = 0, but the curent call list
> indicates at least one call is held" and "AG IUT does not report
> (callheld=1) (does not report that there is both a held and active call)."

I would like to mention one thing more:

For the TP/ECS/BV/01-I,
the test purpose is to verify AG can correctly respond CLCC.
I just pass this case using GSM phone and all I need is this GSM phone(AG) and "ONE" external line,
however, I observed that your snoop and PTS log has two calls listed:

- AT: +CLCC received: +CLCC: 1,1,1,0,0,"02131362666",129 ----[1]
- AT: +CLCC received: +CLCC: 2,1,0,0,0,"18516656636",129
- FATAL ERROR (AT): var_twc.held_calls = 0, but the curent call list indicates at least one call is held

Is the case related with second call?

[1] 3rd "1" of 1,1,1,0,0 means this call is "Held"

====

My log FYI:
- AT: +CLCC received: +CLCC: 1,1,0,0,0,"0973xxxxxx",129
- MTC: +CLCC responses correctly indicate one active and one held call in the status field.

Comment 20

[Lingling Zhao]

In our the test for TP/ECS/BV/01-I, two external line are needed. The same thing is happened in our FFOS2.0 GMS devices.

Comment 21

[Lingling Zhao]

For case TP/TCA/BV-05-I, its purpose is “the AG in the presence of an incoming
waiting call, terminates the active call upon receiving AT+CHUP command from the HF
device".

When CHUP is received, gaia try to hang up the active call, but both of the incoming waiting call and active call will be hanged up, because actually these two calls are different parts of the same call, it is different from GSM phones. 
If I modify to donot hangup the active call, the case cannot pass either.

Can you help me to solve this problem?

Thanks.

Comment 22

[Will Wang [:WillWang]]

(In reply to Lingling Zhao from comment #20)
> In our the test for TP/ECS/BV/01-I, two external line are needed. The same
> thing is happened in our FFOS2.0 GMS devices.

Before discussing specific PTS test case, I would like to address one thing:

I noticed that your snoop log shows the PTS software version is out of date:
PTS Message	PTS: v6.0 Build 16

Latest(and currently used in Mozilla): 6.3.0 build 19

Could you update it and check whether the test procedure is changed or not, and test again?
And you might need to be aware of changes of other related test cases and perform corresponding tests.

I believe this can benefits the actual bluetooth certification you will take, and our further discussion,
thanks!

Comment 23

[Will Wang [:WillWang]]

Hi Lingling

Furthermore,
Would your device support TWC(Three Way Calling)?
Since you mentioned it in comment 1 but didn't list PTS TWC cases in bug description (comment 0),
I just want to raise this for your information.

It would be better if you can list all related PTS cases you need to pass here. And which of them are currently failed? or only TP/TCA/BV/05-I is failed now?

Comment 24

[Lingling Zhao]

Hi Will,

The fail cases in our test are:
1. TWC cases
 In our android CDMA device which has passed the bluetooth certification, these cases are marked as "not suitable for CDMA device". so we donot pay attention to try to solve them.

2. TP/ENO/BV-01-I
TP/ACC/BI-14-I
TP/ACC/BV-08-I
These three cases are also FAIL in Flame 2.2, so they are not supported by FFOS 2.2.

3.TP/ECC/BI-03-I
TP/ECS/BV-01-I
TP/ECS/BV-02-I
TP/ECS/BV-03-I
TP/TCA/BV-05-I
ECC and ECS cases have been just fixed. TP/TCA/BV-05-I is still fail.

So TP/TCA/BV-05-I is the only case we have to work on it at present.

Comment 25

[Lingling Zhao]

Hi All,

TP/TCA/BV-05-I is PASS now.
To hang up the active call, both of the calls will be hanged up, but the second incoming call will re-come after almost 2s. This is the result under ShangHai's CDMA network, so the case passes.

Incoming call donot re-come under Xi'an 's CDMA network.

Comment 26

[Will Wang [:WillWang]]

Hi Lingling,

Will you still deal with TP/TCA/BV-05-I under Xi'an CDMA network?

Besides,
Is test procedure of TP/ECS/BV/01-I changed after PTS software upgrading?

Thanks!

Comment 27

[Lingling Zhao]

Hi Will,

The PTS software is not upgraded, it is still the old one.

Because of the difference of CDMA network, I made a mistake in dealing with this case.
The last case TP/ECS/BV/01-I is PASS now, so I think you can close this bug.

Thanks for all your support.