1002418 - Desktop client should let the user handle incoming call notifications when already on a call

Status: RESOLVED WONTFIX

(Hello (Loop) :: Client, defect, P5)

Description

[Mark Banner (:standard8)]

Currently the LoopService only opens one chat window per push request.

If we've got two calls queued up, then the user will only get a call prompt for the first call, the other will be silently lost.

Comment 1

[Romain Testard [:RT]]

This seems like a fairly edge case and a complex scenario to implement?
The scenario obviously has to be handled although is it not simpler to fail the call (no UX impact - this is just considered a failed call similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1000186) at least for MVP given it is an edge case.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Right... the only thing I was assuming was a blocker was a call being silently lost.  I'd propose that this bug be modified to clarified to cover explicitly just making the call fail non-silently.

Comment 3

[Mark Banner (:standard8)]

(In reply to Dan Mosedale (:dmose) from comment #2)
> Right... the only thing I was assuming was a blocker was a call being
> silently lost.  I'd propose that this bug be modified to clarified to cover
> explicitly just making the call fail non-silently.

My expectation was, that we'd at least have some notification to the call receiver that they've had an incoming call, but were already in one. Or even the option to put on hold & swap.

Comment 4

[:shell escalante]

need UI for this scenario, not sure what it needs to look like.  from a protocol perspective -what does it look like.

Comment 5

[Darrin Henein [:darrin]]

So how will this feature be handled? Will we be able to do hold & swap? Or should we just notify the user that there is an incoming call but they can't answer (or Hang Up & Answer)?

Just wanted clarity on the technical side before committing to UX.

Comment 6

[Adam Roach [:abr]]

(In reply to Darrin Henein [:darrin] from comment #5)
> So how will this feature be handled? Will we be able to do hold & swap? Or
> should we just notify the user that there is an incoming call but they can't
> answer (or Hang Up & Answer)?
> 
> Just wanted clarity on the technical side before committing to UX.

Technically, we could make the handling here pretty much anything we want to. That said, more complex handling means more complex implementation, and we've got a lot on our plate for MVP.

I would suggest that, for this round, the client simply declines the second (and subsequent) incoming calls with a reason of "busy" (without necessarily notifying the user). But the network protocols can support hold & swap just fine, so we probably want to add that as a feature post-MVP.

Comment 7

[Maire Reavy [:mreavy]]

Do we want this bug to become "decline the second incoming call and return busy"?  Or do we want to keep this bug as the ultimate solution and open a new bug for the interim solution?

If no one cares, let's open a new bug with a simple interim solution.

Comment 8

[Romain Testard [:RT]]

I created https://bugzilla.mozilla.org/show_bug.cgi?id=1032700 to track the MVP requirement.
I am moving this bug to the backlog and renaming with a more explicit name.

Comment 9

[Mark Banner (:standard8)]

This bug morphed a bit, but I'll post the original issue into bug 1032700 as that'll need fixing there anyway.

Comment 10

[:shell escalante]

move back into 34 if you think we can fight for these scenarios - but with over 100 bugs... i'm thinking the second call coming in scenarios are in Fx35.

Comment 11

[Romain Testard [:RT]]

(In reply to sescalante from comment #10)
> move back into 34 if you think we can fight for these scenarios - but with
> over 100 bugs... i'm thinking the second call coming in scenarios are in
> Fx35.

Yes totally, my mistake as I moved as a blocker for desktop backlog but left the target milestone set to FF34

Comment 12

[Maire Reavy [:mreavy]]

This bug is now about "swap and hold" which I think will wait until Fx36 (or later).

Comment 13

[:shell escalante]

P5 based on calls specific volume

Comment 14

[Mark Banner (:standard8)]

We are currently reworking the Loop "user journey" (bug 1209713) and as part of this direct calls and contacts are being removed. Therefore closing direct call related bugs as wontfix.

Tracking id: directcallclosing