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

RESOLVED WONTFIX

Status

Hello (Loop)
Client
P5
normal
Rank:
59
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: RT, Unassigned)

Tracking

unspecified
Points:
3
Bug Flags:
firefox-backlog +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxos], URL)

User Story

As a standalone UI link clicker in a call with a FFOS user, I get notified that my call is being placed on hold visual and audio notifications so that I know that I the person I am in a call with can't hear me anymore.

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
User Story: (updated)

Updated

4 years ago
Assignee: nobody → dhenein
Status: NEW → ASSIGNED
Whiteboard: p=3 s=33.3 [qa-]
(Reporter)

Comment 2

4 years ago
Created attachment 8458608 [details]
Call Hold.mp3

Initial sound file which may change later.

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 3

4 years ago
Why is this marked as resolved?
Flags: needinfo?(mmucci)
(In reply to Romain Testard [:RT] from comment #3)
> Why is this marked as resolved?

Chad informed me it was.
Flags: needinfo?(mmucci)
(Reporter)

Comment 5

4 years ago
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?
Flags: needinfo?(cweiner)
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?
Flags: needinfo?(oteo)
(Reporter)

Comment 7

4 years ago
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?
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?
(Reporter)

Comment 9

4 years ago
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
Flags: needinfo?(oteo)
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.
Flags: needinfo?(oteo)
Flags: needinfo?(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.
(Reporter)

Comment 12

4 years ago
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"?
(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?
Flags: needinfo?(rtestard)
(Reporter)

Comment 14

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

Thanks!
Flags: needinfo?(rtestard) → needinfo?(mozilla-support)
(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.
It still doesn't require Loop server integration. This is all handle between clients via TokBox signaling and events.
(Reporter)

Comment 17

4 years ago
Thanks Fernando, clearing the NeedInfo then.
Flags: needinfo?(mozilla-support)
See Also: → bug 1043971
 
> 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.
(Reporter)

Comment 19

4 years ago
Re-opening as needed but for Fx36.
Status: RESOLVED → REOPENED
Flags: needinfo?(cweiner)
Priority: P2 → P1
Resolution: FIXED → ---
Target Milestone: mozilla34 → mozilla36
Un-assigning until its on the desktop backlog for now.
Assignee: dhenein → nobody

Updated

4 years ago
Points: --- → 3
Flags: qe-verify-
Flags: firefox-backlog+
Whiteboard: p=3 s=33.3 [qa-]

Updated

4 years ago
backlog: --- → Fx38+
Status: REOPENED → NEW

Updated

3 years ago
backlog: Fx38+ → backlog

Updated

3 years ago
backlog: backlog+ → backlog-

Comment 21

3 years ago
triaged to backlog "-" until we focus on FxOS integration again.
Rank: 59
Priority: P1 → P5
Whiteboard: [fxos]
Target Milestone: mozilla36 → ---
Marking as WON'T FIX since this is not on the agenda anymore (as per bug 1015053)
Status: NEW → RESOLVED
Last Resolved: 4 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.