Closed Bug 1015491 Opened 7 years ago Closed 7 years ago

Desktop client needs to handle initiating calls to contacts with multiple identities

Categories

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

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: dmose, Unassigned)

References

Details

(Whiteboard: [p=?, contacts])

User Story

From the original bug:

If a contact holds multiple identities (e-mail addresses and phone numbers), these multiple identities are sent to the server which will try to connect identities which are registered and connected.

If multiple identities are registered they are all notified though push notifications and the first identity which answers or declines causes all other engaged identities to have their incoming calls cancelled (first who answers or declines wins).
+++ This bug was initially created as a clone of Bug #972017 +++
As far as estimation goes, I can see at least two pieces of work on the client side.

* add the multiple identities to the server so that it can route the cal.

* if my client is ringing and I get an "incoming call cancelled" notification, I need to abort the call.  My suspicion is that since these are presumably to all be the same user, the window can just silently disappear as though it had never happened, instead of giving the user some sort of clue that a call been cancelled.  Darrin, if you disagree, knowing what sort of UX you think we want would be helpful in figuring out whether that work wants to live here or be split out to another bug.
User Story: (updated)
Flags: needinfo?(dhenein)
Priority: P1 → P2
(In reply to Dan Mosedale (:dmose) from comment #1)
> * if my client is ringing and I get an "incoming call cancelled"
> notification, I need to abort the call.  My suspicion is that since these
> are presumably to all be the same user, the window can just silently
> disappear as though it had never happened, instead of giving the user some
> sort of clue that a call been cancelled.  Darrin, if you disagree, knowing
> what sort of UX you think we want would be helpful in figuring out whether
> that work wants to live here or be split out to another bug.

My thought was to show a 'Call Cancelled' label in place of the 'Incoming Call...' label in the window, and after a delay (2-3 seconds?) automatically hide the window. Just want to make sure we inform the user in the case they see the window and are about to click it, etc.

That being said, if the call has not actually been 'Cancelled' by the caller, but rather answered somewhere else, we can just silently dismiss the window. Not sure if we are making this distinction though?
Flags: needinfo?(dhenein)
Target Milestone: --- → mozilla34
I like that; I hadn't thought of the case where someone saw the thing out of the corner of their eye as they walked into the room.

I don't know if the planned network architecture currently makes this distinction, but if not, it seems reasonable to ask what it would take to make it support this.
Whiteboard: p=? → [p=?, contacts]
Target Milestone: mozilla34 → mozilla35
I don't think this is needed for the first release of FxA & contacts
we are putting the bug in that a user who is signed in via oAuth needs to be able to recieve a call via email (bug 1000761) - for Fx34 is that enough? or do we need this bug which basically says when you are logged in - you can be called by any of your identities in the contact address book (like phone number).  not sure if a lot of this work is in place because of FxOS mobile client/server work.
Flags: needinfo?(adam)
(In reply to sescalante from comment #5)
> we are putting the bug in that a user who is signed in via oAuth needs to be
> able to recieve a call via email (bug 1000761) - for Fx34 is that enough? or
> do we need this bug which basically says when you are logged in - you can be
> called by any of your identities in the contact address book (like phone
> number).  not sure if a lot of this work is in place because of FxOS mobile
> client/server work.

The tl;dr for planning purposes is that neither the bug in the user story nor the bug described by the bug title are needed for 34.

However, the user story and the bug title don't match, since one is talking about calling-side behavior, and the other is talking about called-side behavior. This needs to be split into two bugs:

 * One that matches the title. That is, if I have a contact in my contact list who has three email
   addresses and a phone number, then I need to send all three email addresses and the phone number
   to the loop server when I start a call. Of the addresses that are valid, the Loop server should
   then attempt to contact any corresponding registered clients in parallel. You'll note that the
   calleeId field for <https://wiki.mozilla.org/Loop/Architecture/MVP#POST_.2Fcalls> takes an array
   specifically to accommodate this situation.

 * One that matches the user story. That is, if I have multiple confirmed identities, then I either
   send all of these identities to the server when I register, or (more likely) I send my FxA identity
   and the server can loop up my other identities based on that one identity. The Loop server then
   knows that any calls for any of those identities are to be routed to this client.

The first one is actually pretty easy (assuming the server has implemented this functionality, and I suspect it has), and we can add it to 34 if time allows -- but it's not extremely critical.

The second one is pretty complex, and requires additional architectural design (and coordination with the FxA team) to determine how we want to validate and associate additional callable identities with an FxA account.
Flags: needinfo?(adam)
(In reply to Dan Mosedale (:dmose - needinfo? me for responses) from comment #3)
> I like that; I hadn't thought of the case where someone saw the thing out of
> the corner of their eye as they walked into the room.
> 
> I don't know if the planned network architecture currently makes this
> distinction, but if not, it seems reasonable to ask what it would take to
> make it support this.

Yes, it does. Check https://wiki.mozilla.org/Loop/Architecture/MVP#Termination_Reasons
(In reply to Adam Roach [:abr] from comment #6)

>  * One that matches the user story. That is, if I have multiple confirmed
> identities, then I either
>    send all of these identities to the server when I register, or (more
> likely) I send my FxA identity
>    and the server can loop up my other identities based on that one
> identity. The Loop server then
>    knows that any calls for any of those identities are to be routed to this
> client.
> 
> [...]
> 
> The second one is pretty complex, and requires additional architectural
> design (and coordination with the FxA team) to determine how we want to
> validate and associate additional callable identities with an FxA account.

It seems that this is related to identity linkage as described at https://wiki.mozilla.org/Loop/Architecture/ID#Linking_accounts and I believe we moved that out of the scope of MVP.
Blocks: 1066017
No longer blocks: 1012743
should we consider this part of clean-up or is this more fx38?
backlog: --- → Fx38?
Flags: needinfo?(standard8)
Target Milestone: mozilla35 → ---
I've split the second part of comment 6 out to bug 1089696 - for future implementation.

The first part of comment 6 is already fixed and implemented.

Hence, at a toss-up, I'll resolve this as WFM.
Blocks: 1089696
Status: NEW → RESOLVED
backlog: Fx38? → ---
Closed: 7 years ago
Flags: needinfo?(standard8)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.