Created attachment 8555921 [details] 2015-01-28-16-43-31.png Env: Desktop, FireE comercial build Loop v1.1.1/d4d6d37 User_A logged in loop from mobile_A User_B logged in lopp from Desktop User_C logger in lopp from mobile_C STR: 1.- From mobile_A an Desktop, establish a room communication between User_A and User_B. 2.- Once communication is established, make a Loop call from mobile_C to User_A. ACTUAL RESULT: AR1: Room conversation established in step 1, is not closed, and User_B doesn't receive any message. AR2: Video received on Desktop remains frozen. AR3: Once Loop call from mobile_C is established, this call seems to be a multi conference among the three. (User_A and User_B, receive audio from User_C). AR4: After hanging up the loop call from mobile_A, this message is received: "Sorry, we have problems on our side. Please try again" (please, see attached picture)
In step-2, if the room conversation is in background (pressing home button), when loop call is received, User_B receives the notification right ("You are the only one in the room"). But, after closing the loop call in mobile_A, the screen attached is received too.(AR4).
Sadly we are not handling FxOS Hello conversation interruptions while a FxOS Hello room conversation is active. I'll take the bug to figure out how we can handle this situation. Either case I'd like to have some feedback from the product/UX team if possible. I see two possible options, i) reject the call or ii) close the room conversation and accept the call.
Assignee: nobody → josea.olivera
Created attachment 8556405 [details] [review] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/532 Dev team agreed with product team that incoming FxOS Hello calls must be rejected (with busy reason) if a FxOS Hello room is active. That's what the patch in this pull request implements. Working fine, low risk. Borja, Cristian I'd like to have some feedback from you guys please. Thanks!
Comment on attachment 8556405 [details] [review] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/532 If I were you I would add params.action = 'reject' instead of roomActive
Attachment #8556405 - Flags: feedback?(crdlc) → feedback+
Comment on attachment 8556405 [details] [review] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/532 Thanks Cristian, could you go for the review them? Thanks!
Attachment #8556405 - Flags: feedback?(borja.bugzilla) → review?(crdlc)
Comment on attachment 8556405 [details] [review] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/532 LGTM, an elegant approach and solution, good job José! Maria Angeles, would you like to try this before landing? Thanks
Landed on master branch at: https://github.com/mozilla-b2g/firefoxos-loop-client/commit/f54322b9648ea9f8c4efef8ea7fcc3d39c269330 PS. Javier tested this. Gave feedback positive offline. I was told by Maria to cancel the feedback request at her.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Whiteboard: [Room1.1.1_TestRun2] → [Room1.1.1_TestRun2][Not in 1.1.1]
Works perfect! and JA has confirmed that the patch is low risk :) Please, go ahead with the uplifting!!! Thanks a lot to all of you!
Whiteboard: [Room1.1.1_TestRun2][Not in 1.1.1] → [Room1.1.1_TestRun2][Not in 1.1.1][loop approved for 1.1.1]
Attachment #8556405 - Flags: feedback?(oteo) → feedback+
Landed on 1.1.1 branch at: https://github.com/mozilla-b2g/firefoxos-loop-client/commit/53c1186f153a8fc27b1bc043c20d424981487156
Whiteboard: [Room1.1.1_TestRun2][Not in 1.1.1][loop approved for 1.1.1] → [Room1.1.1_TestRun2][loop approved for 1.1.1][In 1.1.1]
Hi All, I have been seen an issue that think should be fixed with this patch: User A desktop User B mobile User C mobile STR User A and B are in a room User C makes a loop call to user B EXPECTED If I understood well what discussed in this bug, user C should hear the busy tone and see the corresponding message ACTUAL User C start the call, the device shows dialing and after a few seconds that screen is closed and user is taken to room list without any feedback. Let me know if you prefer to reopen or file a new bug with this scenario. Thanks!
(In reply to Isabel Rios [:isabel_rios] from comment #12) > If I understood well what discussed in this bug, user C should hear the busy > tone and see the corresponding message That's exactly what we fixed in this bug. > Let me know if you prefer to reopen or file a new bug with this scenario. > Thanks! Let me have a look and I'll get back to you as soon as I figure out what's happening. Thanks!
The device being interrupted by the Hello call rejects the incoming call correctly but the device being rejected is not handling the reject (busy reason) correctly. It seems this is because how fast the reject message reaches the device being rejected. I could fix this as a follow-up of this bug. Could you file the bug and assign it to me please? Thanks!
Thanks Jose Antonio for your feedback! I will file a bug in a bit
Pull request ready for the follow-up at https://github.com/mozilla-b2g/firefoxos-loop-client/pull/561. I'll attach it to the bug once you file it. Thanks!
Done! Bug 1129979 Thanks!
Verified on fireE, v2.0 comercial version. Loop version 1.1.1/39a5284
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.