1028888 - Standalone UI for link clickers needs "call on hold" visual and audio notification

Status: RESOLVED WONTFIX

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

Description

[Romain Testard [:RT]]

This is necessary for FFOS / Desktop call scenarios.
On FFOS when on a Loop call if a cellular incoming call occurs, the Loop call is placed on hold in the background and then resumed at the end of the call.

The partner SDK exposes an "on hold" feature and this does not require Loop server integration.

The FF desktop user cannot place a call on hold or resume a call manually. 
This bug is only about notifying a user that the call is placed on hold.
All other call controls are although available when a user's call is placed on hold, including call termination.

Comment 1

[Romain Testard [:RT]]

UX: https://people.mozilla.org/~dhenein/labs/loop-link-spec/#hold-call

Comment 2

[Romain Testard [:RT]]

Attachment: Call Hold.mp3

Initial sound file which may change later.

Comment 3

[Romain Testard [:RT]]

Why is this marked as resolved?

Comment 4

[Marco Mucci [:MarcoM]]

(In reply to Romain Testard [:RT] from comment #3)
> Why is this marked as resolved?

Chad informed me it was.

Comment 5

[Romain Testard [:RT]]

Chad, we need this for FFOS interrop.
A call can be placed on hold on FFOS (if incoming cellular cold occurs as a FFOS is on a Loop call) and we need a notification on the clicker side that we entered an "on hold" state.

Please confirm you agree?

Comment 6

[Maire Reavy [:mreavy]]

Hi RT -- For bugs like this which are FxOS only (at least for the short term), I'd like for us to ask Maria's team (at TEF) to implement them.  Maria's folks know what they need for their client.  I'm happy to provide reviewers for their standalone work, but I think it will be most efficient and the best experience for everyone if they own bugs like this.   I've done a needinfo to Maria to ask if she is ok with this plan. 

Maria -- Do you think your team could implement this bug and bug 1028890?

Comment 7

[Romain Testard [:RT]]

The scenario is:
1 a FFOS client is in communication with a FF desktop client.
2 The FFOS client receives an incoming cellular call and puts the call on hold
3 The FF desktop client needs to notify the user he has been placed on hold (the user can't do anything)
4 The FFOS client resumes the call
5 The FF dektop client needs to notify the user the call was resumed

So this is FF desktop development, right?

Comment 8

[Maire Reavy [:mreavy]]

This user story for this bug is about the standalone UI (not a signed in user).  Is this bug asking for a sign-in desktop client to support hold/resume notification or for the standalone UI to support hold/resume notification?

Comment 9

[Romain Testard [:RT]]

Apologies - poor use of "FF desktop client" in my previous comment.
This is a standalone UI bug and a scenario where a FFOS user shared a call-back link with a link clicker.

1 a FFOS client is in communication with a FF standalone UI client (link clicker).
2 The FFOS client receives an incoming cellular call and puts the call on hold
3 The FF standalone UI client needs to notify the user he has been placed on hold (the user can't do anything)
4 The FFOS client resumes the call
5 The FF standalone UI client needs to notify the user the call was resumed

Comment 10

[Maire Reavy [:mreavy]]

Ok, cool.  That's what I thought.  So we need the standalone code modified.  The standalone client could be Fx for Android or Google Chrome as well as Fx for Desktop.   I'm asking Maria if this work is something her team could do since they know what they want to see between mobile Loop and the standalone client and hold/resume isn't in the short-term plans for desktop.  If this isn't a priority for mobile (if it's "nice to have" for now), then we can defer this conversation until later.

Comment 11

[Maria Angeles Oteo (:oteo)]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #10)
> Ok, cool.  That's what I thought.  So we need the standalone code modified. 
> The standalone client could be Fx for Android or Google Chrome as well as Fx
> for Desktop.   I'm asking Maria if this work is something her team could do
> since they know what they want to see between mobile Loop and the standalone
> client and hold/resume isn't in the short-term plans for desktop.  If this
> isn't a priority for mobile (if it's "nice to have" for now), then we can
> defer this conversation until later.

Unfortunately we are overloaded right now and we can not take care of implementing this, anyhow, I think it’s not that critical:

As of today, when a call is put on hold, the phone putting the call on hold just stops sending video and audio and the other FxOS party will just stop seeing and listening to the one putting the call on hold. I think Desktop should be ready for that in any case.

In addition to that we are going to send another custom event in that case so we can show a more sophisticated UI (something like “the call is on hold”). We will let you know when the implementation is ready just in case you want to use that event too or check how it has been implemented.

Comment 12

[Romain Testard [:RT]]

My understanding is that the partner SDK exposes an "on hold" feature and this does not require Loop server integration.
Can you please confirm you'll use the SDK feature for "on hold" and "resume"?

Comment 13

[Maria Angeles Oteo (:oteo)]

(In reply to Romain Testard [:RT] from comment #12)
> My understanding is that the partner SDK exposes an "on hold" feature and
> this does not require Loop server integration.
> Can you please confirm you'll use the SDK feature for "on hold" and "resume"?

We are not aware of it :(, can you point us to where that functionality is exposed?

Comment 14

[Romain Testard [:RT]]

Hi TokBox support, can you please confirm if the SDK exposes a feature allowing to put a call on hold and resume it?

Thanks!

Comment 15

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Romain Testard [:RT] from comment #14)
> Hi TokBox support, can you please confirm if the SDK exposes a feature
> allowing to put a call on hold and resume it?
> 
> Thanks!

There is no "call hold" feature on TokBox's SDK. What we have is a signaling API that we use to notify the other side about hold and resume events, apart from the stream publication events that we already have in the SDK.

Comment 16

[Fernando Jiménez Moreno [:ferjm]]

It still doesn't require Loop server integration. This is all handle between clients via TokBox signaling and events.

Comment 17

[Romain Testard [:RT]]

Thanks Fernando, clearing the NeedInfo then.

Comment 18

[Maria Angeles Oteo (:oteo)]

 
> In addition to that we are going to send another custom event in that case
> so we can show a more sophisticated UI (something like “the call is on
> hold”). We will let you know when the implementation is ready just in case
> you want to use that event too or check how it has been implemented.

We have created Bug 1043971 to implement it in Loop Mobile Client side.

Comment 19

[Romain Testard [:RT]]

Re-opening as needed but for Fx36.

Comment 20

[Darrin Henein [:darrin]]

Un-assigning until its on the desktop backlog for now.

Comment 21

[:shell escalante]

triaged to backlog "-" until we focus on FxOS integration again.

Comment 22

[Mark Banner (:standard8)]

Marking as WON'T FIX since this is not on the agenda anymore (as per bug 1015053)