1053155 - [Loop] In Loop Call BEING ESTABLISHED, if GSM call is answered, changing to Loop App, before answering Lopp call, GSM call is put on hold.

Status: RESOLVED WONTFIX

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

Description

[Javier de Prado]

Device: Flame / FireE
Loop Version: 609ec57

STR: 
1.- Device-A makes a Loop call to Device-B
2.- Before answering the Loop call, Device-C makes a GSM call to Device-B
3.- Device-B answers the GSM call and the GSM call is established.
4.- In Device-B, change to Loop App (the loop call has not yet been answered)


ACTUAL RESULT:
The GSM call is put on hold automatically

EXPECTED RESULT:
GSM call shouldn't be put on hold until the Loop call is established (not before).
 
According to the AC in https://bugzilla.mozilla.org/show_bug.cgi?id=1034460):
Case F: Loop Call being established, GSM call is answered and Loop call is established afterwards
- If during the establishing process of a Loop call (either incoming or outgoing) a GSM call is received and answered, GSM call will be established. If the user completes afterwards the establishment of the Loop call, GSM call will be put on hold.

Comment 1

[Javier de Prado]

Tested again and It's still happening. ...: when 4.- In Device-B, change to Loop App (the loop call HAS NOT YET BEEN ANSWERED)

Device: Flame
Build: v2.0 with kk v180 (Gecko-9362b48.Gaia-263e3b2)
Loop version: 041ff17
RAM: 512M

Comment 2

[bhavana bajaj [:bajaj]]

Ni :mreavy to comment here. Maire is this a gecko or the loop app issue ? If its the former can you please help with assignee or help with next steps. CAF deems this as a blocker for 2.1 release.

Comment 3

[Inder]

[Blocking Requested - why for this release]:

Comment 4

[Maire Reavy [:mreavy]]

For this you want to ask one of the audio channel folks (e.g. Andrea Marchesini, Starr Cheng, or Marco Chen).  This is not a core WebRTC issue or Loop issue, but a matter of how the channels get handled and what the relative priority is among the channels.

Comment 5

[José Antonio Olivera Ortega [:jaoo]]

I want to have a look at it asap. The issue might be caused by the timing of the mozinterrupt{begin, end} events fired on the callscreen app when it is interrupted by a WebRTC call.

Comment 6

[Dietrich Ayala (:dietrich)]

Triage reviewed and marked blocking+ for commercialization requirement.

Comment 7

[bhavana bajaj [:bajaj]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #5)
> I want to have a look at it asap. The issue might be caused by the timing of
> the mozinterrupt{begin, end} events fired on the callscreen app when it is
> interrupted by a WebRTC call.

can you please help us with an ETA on the patch here, given it needs to hit the CAF certification testing date in the next week.

Comment 8

[José Antonio Olivera Ortega [:jaoo]]

(In reply to bhavana bajaj [:bajaj] from comment #7)
> can you please help us with an ETA on the patch here, given it needs to hit
> the CAF certification testing date in the next week.

To be realistic I don't see this fixed for the next week. The fix involves to debug three parts which are the audio channel plumbing and both the callscreen and the loop app and find the root cause of it. I can't give you an ETA then.

Comment 9

[Maria Angeles Oteo (:oteo)]

According to comment 8, Andrea, can you help us with this issue please?
Thanks a lot!

Comment 10

[José Antonio Olivera Ortega [:jaoo]]

This is a corner case in which the device receives two incoming calls at the same time. As both apps callcreen and loop are playing the ring tone as the same time (using the ringer audio channel) the first app the user answers will be set on hold as the ringer audio channel has higher priority than the telephony one. So having said that this bug should be closed as WONTFIX or WORKSFORME. I'll talk to Andrea today about it.

Comment 11

[Maria Angeles Oteo (:oteo)]

 (In reply to José Antonio Olivera Ortega [:jaoo] from comment #10)

I completely agree, it's an ugly bug but it's not a common case as Jose Antonio has commented (device receives two incoming calls at the same time) Besides, we are not hanging up any call and we can always resume the GSM or Loop the call.

Apart of that, it can not be resolved only on Loop mobile client side, fixing this will imply to change/review the audio channel policy in the platform that it is something extremely risky as we are really late for this kind of changes in 2.0 or 2.1. I would suggest to do it for 2.2

Kumar, do you agree with removing the nomination? Thanks a lot

Comment 12

[Jay]

Maria,

I agree that we can remove this from 2.0/2.1 as it is not a complete functional failure and seems to be quite involve to get this resolved based on the feedback.

Comment 13

[bhavana bajaj [:bajaj]]

(In reply to Maria Angeles Oteo (:oteo) from comment #11)
>  (In reply to José Antonio Olivera Ortega [:jaoo] from comment #10)
> 
> I completely agree, it's an ugly bug but it's not a common case as Jose
> Antonio has commented (device receives two incoming calls at the same time)
> Besides, we are not hanging up any call and we can always resume the GSM or
> Loop the call.
> 
> Apart of that, it can not be resolved only on Loop mobile client side,
> fixing this will imply to change/review the audio channel policy in the
> platform that it is something extremely risky as we are really late for this
> kind of changes in 2.0 or 2.1. I would suggest to do it for 2.2

Sounds good, I'll remove it from 2.1. If this has to be addressed in audio channel , involving :baku to help here.
> 
> Kumar, do you agree with removing the nomination? Thanks a lot

Comment 14

[Andrea Marchesini [:baku]]

I agree with jaoo. This is a corner case. I don't have any solutions except changing the priority ringer vs telephony. But this is a big change and I don't think we want to do this for 2.1.

Comment 15

[Stephany Wilkes]

Removing 2.2? flag and backlogging this, because this looks like a corner case that got booted from 2.1 to 2.2, isn't actively being worked on, and is not in 2.2 scope. Please re-nom as necessary.

Comment 16

[José Antonio Olivera Ortega [:jaoo]]

I'm not working on this so I'm leaving it unassigned so someone else can work on it. Sorry. Thanks!

Comment 17

[BMO Automation]

Firefox OS is not being worked on