Closed Bug 890807 Opened 7 years ago Closed 7 years ago

[User story][CDMA] Call waiting

Categories

(Firefox OS Graveyard :: RIL, defect, P1)

x86
macOS
defect

Tracking

(blocking-b2g:koi+, firefox26 fixed)

RESOLVED FIXED
blocking-b2g koi+
Tracking Status
firefox26 --- fixed

People

(Reporter: khu, Unassigned)

References

()

Details

(Whiteboard: [ucid:CDMA3, FT:RIL, KOI:P1])

User story: 

As a user, I need to know via UI which of the callers is waiting and which of the callers is on line. 
As a user, I need to be able to switch calls between the calls waiting and active. 

Acceptance criteria: 

User should know via UI which of the callers is waiting and which of the callers is on line and be able to switch.
blocking-b2g: --- → koi+
Depends on: 882980, 873006
Also depends on Gaia and BT bugs.
Flags: in-moztrap?
QA Contact: echu
Hi Sandip,

For the acceptance criteria, here are what I suggest:
1. User can connect to the call which is hold after the active one ends the call with user.
2. User can get call notification from the hold one after he/she ends the active call. (But this might depends on whether network is supported)

Thanks,
Enpei
Talked with UX, QA and CDMA experts: 

We can't get the status of call waiting. But, whenever there comes a new phone call, we can get the number at that time. The problem is, we don't know the status when switching between phone calls. 

For UX, we may need a UX for call waiting / switching. Before that, we need to know current status.
Current status is, after enabling call waiting, current Firefox OS can display call switching, and also display the incoming number when switching. But, for CDMA, we can't know the incoming numbers.
Sandip, in CDMA network, we can't meet the following requirement: 
"As a user, I need to know via UI which of the callers is waiting and which of the callers is on line. "
It's a limitation of CDMA network. We suggest to remove this requirement. What do you think? 

For switch, at most we can do is to provide a "switch" button. But, when switching, we can't know which call we switched to, and we don't know if the callers hang up the phone call. In this case, Sandip, do you still want to implement this user story? 

Thank you.
Flags: needinfo?(skamat)
Khu/Sandip, this is precisely why Android only shows a generic UI when a call waiting call is accepted.
Thanks, Anshul. 

My suggested user story is: 
"As a user, I need to be able to switch calls between the calls waiting and active."

Sandip, what do you think?
(In reply to khu from comment #7)
> Thanks, Anshul. 
> 
> My suggested user story is: 
> "As a user, I need to be able to switch calls between the calls waiting and
> active."
> 
> Sandip, what do you think?

yes, Generic UI is fine. I will update the User story.
Flags: needinfo?(skamat)
Priority: -- → P1
Flags: in-moztrap? → in-moztrap?(echu)
Whiteboard: [ucid:CDMA3] → [ucid:CDMA3], [FT:RIL]
Whiteboard: [ucid:CDMA3], [FT:RIL] → [ucid:CDMA3], [FT:RIL], [Test case ETA:8/12]
Whiteboard: [ucid:CDMA3], [FT:RIL], [Test case ETA:8/12] → [ucid:CDMA3, FT:RIL, KOI:P1], [Test case ETA:8/12]
Update test case URL but minor revise will be needed for UX changes.
Flags: in-moztrap?(echu) → in-moztrap+
We can finish it today, and do the verification tomorrow.
Component: General → RIL
QA can verify this bug. Move BT HFP to 1.3.
Status: NEW → RESOLVED
Closed: 7 years ago
No longer depends on: 873006
Resolution: --- → FIXED
Test on wasabi:
Gaia:     2d870100a945272824f8e42a8c52aac095fe907e
B-D     2013-09-11 04:59:20
Gecko:    46c335b301fdb32f47e58c665190ffc41522ae00
BuildID   20130911062051
Version   26.0a1

Issues will be filled in "depend on".
Depends on: 915494, 915081, 915074, 915071, 914967
Depends on: 922582, 922574
Whiteboard: [ucid:CDMA3, FT:RIL, KOI:P1], [Test case ETA:8/12] → [ucid:CDMA3, FT:RIL, KOI:P1]
No longer depends on: 922574
Depends on: 927062
Depends on: 928597
Depends on: 928700
You need to log in before you can comment on or make changes to this bug.