Closed Bug 1126860 Opened 9 years ago Closed 9 years ago

[Loop] Wrong status in a room conversation when receives a loop call.

Categories

(Firefox OS Graveyard :: Gaia::Loop, defect)

x86
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: javier.deprado, Assigned: jaoo)

References

Details

(Whiteboard: [Room1.1.1_TestRun2][loop approved for 1.1.1][In 1.1.1])

Attachments

(2 files)

Attached image 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
Status: NEW → ASSIGNED
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!
Attachment #8556405 - Flags: feedback?(crdlc)
Attachment #8556405 - Flags: feedback?(borja.bugzilla)
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
Attachment #8556405 - Flags: review?(crdlc)
Attachment #8556405 - Flags: review+
Attachment #8556405 - Flags: feedback?(oteo)
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
Closed: 9 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!
Flags: needinfo?(josea.olivera)
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
Flags: needinfo?(josea.olivera)
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!
Flags: needinfo?(isabelrios)
Thanks Jose Antonio for your feedback!
I will file a bug in a bit
Flags: needinfo?(isabelrios)
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.

Attachment

General

Created:
Updated:
Size: