1052400 - [Loop] Cannot set up Loop call on incoming/outgoing GSM/CDMA call

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 GSM call to device-B, and device-B doesn't pick up the phone.
2.- While GSM call is being established, device-C makes a LOOP call to device-A (or device-B).
3.- Device-A (or device-B) answer LOOP call with audio button (or video button)

ACTUAL RESULT:
Loop call can't be established.

EXPECTED RESULT:
Loop call should be established according AC (case C) in https://bugzilla.mozilla.org/show_bug.cgi?id=1034460

Comment 1

[Borja Salguero [:borjasalguero]]

Any update or log here?

Comment 2

[Javier de Prado]

Attachment: bug1052400.txt

Same error as in https://bugzilla.mozilla.org/show_bug.cgi?id=1069793

"...09-24 13:06:17.088 E/GeckoConsole( 3286): Content JS LOG at app://loop.services.mozilla.com/call_screen/js/call_screen_ui.js:83 in CallScreenUI.init/<: An error occured! Permission Denied
09-24 13:10:01.628 E/GeckoConsole( 3286): Content JS LOG at app://loop.services.mozilla.com/call_screen/js/call_screen_ui.js:83 in CallScreenUI.init/<: An error occured! Permission Denied
"

Comment 3

[Javier de Prado]

Tested on:

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

Comment 4

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Javier de Prado from comment #2)
> Created attachment 8494429 [details]
> bug1052400.txt
> 
> Same error as in https://bugzilla.mozilla.org/show_bug.cgi?id=1069793
> 
> "...09-24 13:06:17.088 E/GeckoConsole( 3286): Content JS LOG at
> app://loop.services.mozilla.com/call_screen/js/call_screen_ui.js:83 in
> CallScreenUI.init/<: An error occured! Permission Denied
> 09-24 13:10:01.628 E/GeckoConsole( 3286): Content JS LOG at
> app://loop.services.mozilla.com/call_screen/js/call_screen_ui.js:83 in
> CallScreenUI.init/<: An error occured! Permission Denied
> "

Same as https://bugzilla.mozilla.org/show_bug.cgi?id=1069793#c5

Comment 5

[Javier de Prado]

I've tested again, and It's working fine on fireE (firee-kk-v2.0-SW2E3-1)
Loop version: 1.1 , 2168965

Comment 6

[Javier de Prado]

Only when GSM call is outgoing call, It's still happening.

STR (FAIL):
1.- Device-A makes a GSM call to device-B, and device-B doesn't pick up the phone.
2.- While GSM call is being established, device-C makes a LOOP call to DEVICE-A.
3.- Device-A answer LOOP call with audio button (or video button)

STR (OK):
1.- Device-A makes a GSM call to device-B, and device-B doesn't pick up the phone.
2.- While GSM call is being established, device-C makes a LOOP call to DEVICE-B.
3.- Device-B answer LOOP call with audio button (or video button)

Comment 7

[José Antonio Olivera Ortega [:jaoo]]

A WebRTC call is only possible either when there is no GSM/CDMA call at all or the GSM/CDMA call is on hold. When the GSM/CDMA call is connected -if this is interrupted by a WebRTC call- we are able to set it on hold because the callscreen app is notified of that interruption via mozoninterruptbegin events. On the down side when the GSM/CDMA call is either incoming or dialing there is no way to set in on hold so sadly the Loop app cannot set up the WebRTC call. On incoming/outgoing GSM/CDMA calls there is no way to get the V/A stream correctly (via gUM) previous to the WebRTC call. I guess this is because the V/A resources are in use for telephony stack. Having said that IMHO we should resolve this bug as either WORKSFORME or WONTFIX.

Comment 8

[Maria Angeles Oteo (:oteo)]

agree with Jose Antonio, right now we can not fix this issue, many platform changes in the audio channel policy that are really risky and should need more time to be thought, implemented and tested to ensure nothing is regressed.
Closing the bug as won't fix but moving the bug to the meta for the pending issues in 1.1 so we can analyze later if it could make sense this changes for future releases.

Comment 9

[Javier de Prado]

Ok. But, meanwhile, I suggest that if possible, the AC should be modified according to this behaviour.
C case, in https://bugzilla.mozilla.org/show_bug.cgi?id=1034460

Comment 10

[Maria Angeles Oteo (:oteo)]

(In reply to Javier de Prado from comment #9)
> Ok. But, meanwhile, I suggest that if possible, the AC should be modified
> according to this behaviour.
> C case, in https://bugzilla.mozilla.org/show_bug.cgi?id=1034460

You are right, I'll review them and update them