1198146 - [GC][FFOS 2.2][Call]Incoming call will end all call when make one outgoing call.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Vendcom, defect)

Description

[Lingling Zhao]

Reproduction steps:
Device under test is A, other devices are B and C.
1. B makes a call to A at the same time A makes a call to C.
2. Call B-A will be end,and MS has no call coming, but B is still in calling--ko

Comment 1

[Johan Lorenzo [:jlorenzo]]

In order to find which component is impacted, could you attach logs with RIL debug on[1]?

[1] https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#RIL_Debugging

Comment 2

[Lingling Zhao]

Attachment: logcat20150804_192905.log

Correct 2:Call C-A will be end.

Please see the log in attachment.

Comment 3

[Lingling Zhao]

Hi Johan,

Please see the log in attachment first, I cannot reproduce this bug in my side but my college in other county can reproduce it.

From the log we find when the issue happens, there are two calls in the fact:
1. but because conn[0] is not the same as rilCall[0], so the outgoing call A-C is dropped,the incoming call A-B is kept:
08-04 19:29:50.571 V/CALL_TRACKER(  251): HandlePollCall, conn[0]=ACTIVE,rilCall[0]=INCOMING
08-04 19:29:50.571 V/CONNECTION(  251): Connection CompareTo
08-04 19:29:50.571 D/CALL_TRACKER(  251): New call with same index. Dropping old call
08-04 19:29:50.581 D/RIL     (  251): [SUB0] [0171]> RIL_REQUEST_LAST_CALL_FAIL_CAUSE

2. In gecko telephony, when A makes a call to C, call A-C is created, but this call is updated to call A-B because 1:
08-04 19:29:50.271 I/GeckoDump(  251): dialer:handled_call,number is 18121426887 state is connected
08-04 19:29:50.571 I/GeckoDump(  251): dialer:handled_call,number is 02131362666 state is incoming

3.When call A-C is dropped, gecko telephony gets the message, but because A-C has been updated to call A-B, so call A-B is removed, there is no call screen:
08-04 19:29:50.591 I/GeckoDump(  251): dialer:handled_call,number is 02131362666 state is disconnected

4.In fact, the incoming call A-B is still there untill B to hang up it:
08-04 19:30:05.571 V/CALL_TRACKER(  251): state : 'INCOMING', callIndex : 1, toa :
08-04 19:30:05.571 D/CONNECTION(  251): OnDisconnect index=0 cause=1

Comment 4

[Johan Lorenzo [:jlorenzo]]

Comms triage: Apparently a RIL issue. As far as we know, 2.2 is code complete at the moment. Lingling, can your colleague try the 2.5 version so we can block this release?

Comment 5

[Lingling Zhao]

Hi Johan,

We donot have the 2.5 version at the moment.

Our device is Qualcomm RIL. My college also tested the same situation in Android device with Qualcomm RIL, and it can work well. We find in Android code it has been considered this situation and made a deal with it.

I try to fix it in gecko and gaia, with my patch the incoming call can be received and answered, but the voice cannot be heared in both side.

Can you please take my comment in Comment #3 for reference and check the bug?
Thanks.

Comment 6

[pgravel]

From our analysis of the logs, RIL is correctly telling the TelephonyAudioService to set the phone state to PHONE_STATE_IN_CALL when MT call is answered and we do notify that the call state as changed, but it seems some component along the line is failing to trigger properly and turn the audio on.

This is a somewhat unusual scenario since the MO call becomes the MT call. We can see when making the MO call that the phone transition from IDLE to RINGING to IN_CALL. When the call transitions into an MT call (the call index remains 1, the MO call simply disappears), the state goes back to RINGING (which correct updates the audio back to ringing). As mentioned above, the problem is that when the MT call is answered, the audio doesn't update properly even though Telephony is reporting the correct state.
As a result, I believe there is a component in the audio services/managers line that is failing to handle this scenario, which is even more likely considering the customer has had to make gecko changes to even get the in-call screen to show up.

Unfortunately this is also somewhat hard to reproduce as every network on which we've tried this on prevents this from happening. Attempting to connect to a phone making an MO call simply returns busy or goes directly to voice mail.

Since 2.2 is code complete as johan mentioned, maybe this should be marked as blocking-b2g:2.2r? instead of blocking-b2g:2.2?

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

As this is reported on QCRIL, change the component to Vendcom, thanks.

Comment 8

[pgravel]

Hi Hsin-Yi,

As per comment 6 This seems less like a RIL issue and more like a audio manager issue.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to pgravel from comment #8)
> Hi Hsin-Yi,
> 
> As per comment 6 This seems less like a RIL issue and more like a audio
> manager issue.

Blake, could you please check comment 6? It seems require your team's help.

Comment 10

[Blake Wu [:bwu][:blakewu]]

alwu,
Could you have a look? 
Thanks!

Comment 11

[Alastor Wu [:alwu]]

Keep NI, I'll check it later.

Comment 12

[Alastor Wu [:alwu]]

Hi, Lingling,
I can't understand what is the problem, Could you describe it again?

> "Call B-A will be end,and MS has no call coming, but B is still in calling--ko". 
What's MS? and why B is still calling?
In my observation, the B-A call can't be connected, so we would hear the "the call is busy, please try again later". The A-C call can be connected well. Is this behavior wrong?

I use both v2.2 & v2.5 to test, the result is the same. (B-A fail, A-C success)

Thanks.

Comment 13

[Lingling Zhao]

Hi Alastor,

MS refers to A. When the issue happens, A-C fails, there is NOT a incoming call screen in A, but B is still calling A(no error), and I can see there is a incoming call from B in fact IN THE LOG.

From your result, B-A fail, A-C success, that means you donot reproduce this bug. In your test, the call A-C was created firstly, then B-A was created secondly, so there is nothing wrong. But in this bug, A-C and A-B are created at the same time.

It is difficult to get the point of time exactly, so I cannot reproduce it in my side too, but my college can reproduce it easily. 

Can you please analyze it from the log and the code? They can give much help.

Thanks.

Comment 14

[Alastor Wu [:alwu]]

Add NI flag, check it later.

Comment 15

[Alastor Wu [:alwu]]

Hi, pgravel,

The problem is "the MT call terminates MO call" or "device A doesn't display the incoming call"?
The first problem is related with RIL , and the second one is related with the Gaia callscreen.

The only thing audio manager does is to pass the phone state forward to the Android::AudioPolicyManager.
Therefore, I think the problem shouldn't be related with audio manager. 

Thanks.

Comment 16

[Lingling Zhao]

Let me make it more clearly.

When the MT call and MO call have the same call index, the old call is dropped, so "the MT call terminates MO call" happens, it is due to RIL's strategy, there is no problem.

"device A doesn't display the incoming call" is not only related with gaia callscreen, as the analysis 2. and 3. in comment 3, gecko telephony doesnot give the correct action in this unusual scenario when it should be treated specially.

So I made some changes in gecko and gaia, but new problem cames as I said in Comment 5, and pgravel's analysis in Comment 6 was for the problem in Comment 5.

I agree that there is a component in the audio services/managers line that is failing to handle this special scenario.

Comment 17

[Alastor Wu [:alwu]]

Hi, Lingling,
In comment3, the call A-C (02131362666) is disconnected, is that what you means "the gecko telephony doesn't give the correct action"?
I still think the problem isn't related with audio services/managers, there isn't any specific clues.
We should check telephony service first.

Comment 18

[pgravel]

Hi Alastor,

The problem is that the telephony service is correctly setting the phone state on the audio service to "in call" once the incoming call is answered. We should be seeing a call into AudioPolicyManager which would then call into audio_hw hal -> voice hal -> voice_extn, which is what actually turns on correct audio path.

It may be the problem lies lower than the AudioService, but it would help if you could provide an analysis from the audio perspective while we keep debugging this further since this currently seems like where the disconnect occurs.

I'll upload another set of logs shortly that is a bit more trimmed (starts from the first outgoing call @10:49:59, dialing call gets replaced by the incoming call @10:50:01, answer incoming call @10:50:05, ends with hangup of the call @10:50:18).

Comment 19

[pgravel]

Attachment: logcat20150813_103819_trimmed.log

Comment 20

[praschniker]

[Blocking Requested - why for this release]:

Comment 21

[BMO Automation]

Firefox OS is not being worked on