873006 - [Bluetooth]Support CDMA for Bluetooth HFP profile

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Bluetooth, defect)

Description

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

It is required to handle Call state specially for CDMA.
This is a meta bug to hold all necessary changes for CDMA changes in BluetoothHfpManager.cpp

Comment 1

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

HFP spec was made according to GSM, but for the CDMA case, we need to handle CDMA network.
1. CDMA network does not provide any reply to the phone,
 when the 2nd MO call it goes DIALING > ALERTING -> ACTIVE 
2. CDMA the network does not provide any reply to the phone when a user merges a three way conference call or swaps between two calls.
So it is required to send a CIEV response indicating that a call state got changed.
It should trigger a CLCC update request from phone.
3. We need to handle CDMA for call held special cases

Comment 2

[Francis Lee [:frlee]]

according to the RIL triage meeting consensus on 8/22, koi+ this issue.

Comment 3

[Ben Tian (inactive)]

Bluetooth has to know from RIL/Gaia when user switches call in order to indicate the active call, even if there's no acknowledgement in RIL for the switch.

Hsinyi, can bluetooth know call switch from call state change from RIL? or do you have other suggestion to inform bluetooth call switch?

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Ben Tian [:btian] from comment #3)
> Bluetooth has to know from RIL/Gaia when user switches call in order to
> indicate the active call, even if there's no acknowledgement in RIL for the
> switch.
> 
> Hsinyi, can bluetooth know call switch from call state change from RIL? or
> do you have other suggestion to inform bluetooth call switch?

Hi Ben,

We don't do any call switch in RIL/DOM/Gaia. 
In DOM and Gaia, we get 'cdmaCallWaiting' notification only *once* and the call state remains 'connected' until it's released.

Comment 5

[Ben Tian (inactive)]

Hsinyi,

Per bug 822210 comment 35 gaia would do call.hold() to switch calls (even no guarantee for actual switch). Since bluetooth has to know which 'number' is active, my idea is to keep track of call switch by user and remember current active number in bluetooth. So is there some way for RIL to inform bluetooth of user call switch? Maybe an additional notification?

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Ben Tian [:btian] from comment #5)
> Hsinyi,
> 
> Per bug 822210 comment 35 gaia would do call.hold() to switch calls (even no
> guarantee for actual switch). Since bluetooth has to know which 'number' is
> active, 

But the fact in CDMA is, we have no way to know which number is still active... 
The network won't acknowledge anything.

> my idea is to keep track of call switch by user and remember current
> active number in bluetooth. 

Tracking call switch doesn't really help here. As my above comment, no acknowledgement of the switch or any state changes, even one of remote parties hung the call up. :(

> So is there some way for RIL to inform bluetooth
> of user call switch? Maybe an additional notification?

I am thinking if you want to track call switch request by users, maybe dialer app is the proper one to provide this kind of information since dialer app is that one to initiate the requests? However, the same concern I am always mentioning, tracking call switch doesn't solve the problem with telling which number is exactly active ...

Comment 7

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

moving CDMA HFP to nice to have for v1.2

Comment 8

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

triage: complete this story for CDMA on v1.3

Comment 9

[Ben Tian (inactive)]

HFP supports CDMA now as bug 912005 and 925638 handles the mandatory CLCC command under CDMA network. Note the optional 3-way calling is still unsupported since RIL cannot hangup waiting call (CHLD=1) under CDMA network.

Resolve this bug as fixed.