875686 - [Bluetooth][Certification]Enforce to send callsetup=2 before callheld=1 when doing 3way calling

Status: RESOLVED DUPLICATE of bug 875677

(Firefox OS Graveyard :: Bluetooth, defect)

Description

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

This bug mainly focus on enforce to send callsetup=2 before callheld=1
The reason why do this is as the following:
PTS tool:
1. In the normal case, commands look like:
  ATA
  OK
  +CIEV: 2,1
  +CIEV: 4,0
  AT+BLDN
  OK
  +CIEV: 4,2
  +CIEV: 3,1

2. In failed case, after AT+BLDN,
   +CIEV: 3,1 (call held)
   +CIEV: 4,2  (outgoing call is ongoing)

In the original HFP 1.5 spec, 4.22.2 Three Way Calls – Third Party Call Placed from the HF. Figure 4.26: Three way call handling when the third party call is placed from the HF.
After AT command "ATD", +CIEV: (callheld=1), +CIEV: (callsetup = 2).
This behavior matches that what the problem that Sean mentioned. So basically, nothing is wrong here if using Bluetooth HFP 1.5 spec.

If you checked errta 2459 (Incorrect sequence of indicators update), HFP 1.5 errata had proposed. https://www.bluetooth.org/errata/errata_view.cfm?errata_id=2459

See attachment:
https://www.bluetooth.org/errata/comment_view.cfm?comment_id=5074

Comment 1

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

Attachment: Enforce-to-send-callsetup=2 before callheld=1

Comment 2

[qingluo.wang]

Hi,

Refer to bug 875677,I nominate this bug as 'tef?',please help to check.

Thanks for your support.

Comment 3

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

Hi 
You have two choices:
1. Discuss with BQB lab and claim HFP 1.5 spec, +CIEV: (callheld=1), +CIEV: (callsetup = 2) is correct. So you don't need to modify any code here.

2. Apply this patch

Comment 4

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

Summary:
This bug only can be found on build with commercial ril. Using mozilla ril cannot hit bug because PTS test tool enforce to check CIEV sequence and based on the behavior of different RIL things can different. What Buri behaves by sending  +CIEV: (callheld=1), +CIEV: (callsetup = 2) shall be compatible with HFP 1.5 spec. Please consult with BQB lab first.

Comment 5

[Alex Keybl [:akeybl]]

Marking as POVB based on comment 4, leaving to partners to decide blocking status.

Comment 6

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

Comment on attachment 753663 [details] [diff] [review]
Enforce-to-send-callsetup=2 before callheld=1

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

It's quite hard to understand the condition checks in if-statement, can we simplify them as comments? Please let me know if I missed something.

For static variable of |sUserDialOut|, in order to keep consistency with other variables like |mProcessedBLDN|, I suggest to add a data member in BluetoothHfpManager rather than a static variable in BluetoothHfpManager.cpp. How about |mProcessedCALLHELD|?

::: dom/bluetooth/BluetoothHfpManager.cpp
@@ +1260,5 @@
> +            nsIRadioInterfaceLayer::CALL_STATE_DISCONNECTED) {
> +        // Don't send callheld status, do it until the second call is in
> +        // dialing state
> +        break;
> +      }

if (flag) {
  break;
}

@@ +1305,5 @@
> +        // This is for TWC_BV_05_I
> +        // Send callsetup=2, callheld=1
> +        SendCommand("+CIEV: ", CINDType::CALLHELD);
> +      }
> +

if (flag) {
  SendCommand("+CIEV: ", CINDType::CALLHELD);
}

flag = false;

Comment 7

[qingluo.wang]

(In reply to Shawn Huang from comment #3)
> Hi 
> You have two choices:
> 1. Discuss with BQB lab and claim HFP 1.5 spec, +CIEV: (callheld=1), +CIEV:
> (callsetup = 2) is correct. So you don't need to modify any code here.
> 
> 2. Apply this patch

Hi Shawn,

Thanks for your advice,we will tell the BQB lab about current behavior,and I will remove the 'tef?' flag.

Thanks again for you support.

Comment 8

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

This bug is trying to solve the same problem as bug 875677. According to HFP 1.6 spec, we don't have to enforce the order of callsetup and callheld under this circumstances:

  "There is no enforced order for the callheld and callsetup indicator"

So my suggestion is that, let's solve bug 875677 first and see if the revised code could pass TWC_BV_05_I. If it could, then we close this as resolved invalid or dup.

Comment 9

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

This bug created due to test case AG_TWC_BV_05 test case. We found majority phones on the market sends reverse order- +CIEV: (callsetup = 2), +CIEV: (callheld=1), even some phones declare they support "HFP 1.6" and PTS tool does not take it as a failure case.
See
https://www.bluetooth.org/errata/errata_view.cfm?errata_id=2459
We shall follow that errata and send callheld=2.

Comment 10

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

In bug 875677, we will deal this problem and follow HFP 1.6 spec. Even though both can solve them this problem. We preferred to follow HFP 1.6 spec (HFP 1.5 errata). Mark this as duplicate. Track on bug 875677.

Comment 11

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

Comment on attachment 753663 [details] [diff] [review]
Enforce-to-send-callsetup=2 before callheld=1

Clear ni? since it's been closed as a dup.