Closed Bug 873006 Opened 12 years ago Closed 11 years ago

[Bluetooth]Support CDMA for Bluetooth HFP profile

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

x86_64
Linux
defect
Not set
major

Tracking

(blocking-b2g:1.3+, firefox28 fixed)

RESOLVED FIXED
blocking-b2g 1.3+
Tracking Status
firefox28 --- fixed

People

(Reporter: shawnjohnjr, Assigned: ben.tian)

References

Details

(Whiteboard: [FT:devices, KOI:P2][u=devices c=BT p=0])

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
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
Blocks: b2g-ril-cdma
Severity: normal → major
blocking-b2g: --- → koi?
Assignee: nobody → btian
Depends on: 822210
Blocks: 890807
Blocks: b2g-hfp-16
Depends on: 882980
Whiteboard: [u= c= p=0]
Whiteboard: [u= c= p=0] → [u=devices c=BT p=0]
according to the RIL triage meeting consensus on 8/22, koi+ this issue.
blocking-b2g: koi? → koi+
Blocks: 905580
No longer blocks: b2g-hfp-16
Whiteboard: [u=devices c=BT p=0] → [FT:devices, KOI:P1][u=devices c=BT p=0]
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?
Flags: needinfo?(htsai)
(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.
Flags: needinfo?(htsai)
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?
Flags: needinfo?(htsai)
(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 ...
Flags: needinfo?(htsai)
Depends on: 911986
Depends on: 912005
No longer depends on: 911986
No longer depends on: 882980
Blocks: 1.3-bluetooth
No longer blocks: 905580
blocking-b2g: koi+ → 1.3?
Whiteboard: [FT:devices, KOI:P1][u=devices c=BT p=0] → [FT:devices, KOI:P2][u=devices c=BT p=0]
moving CDMA HFP to nice to have for v1.2
No longer blocks: 890807
triage: complete this story for CDMA on v1.3
blocking-b2g: 1.3? → 1.3+
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.