1010091 - [Sora][Call] The call-screen is not responding after outgoing the second call

Status: RESOLVED DUPLICATE of bug 1007598

(Firefox OS Graveyard :: Gaia::Dialer, defect, P2)

Description

[sync-1]

Mozilla build ID:20140422024003
 DEFECT DESCRIPTION:
  The call-screen is not responding after outgoing the second call
 
  REPRODUCING PROCEDURES:
  1. Click Dialer icon to enter it.
  2. Input 10086 and click the call button to outgoing a call.
  2. Click Add-Call button to outgoing the second call to 10000.
  3. Sometimes the call screen freezes as the picture shows. -ko
 
 When the issue happens, The call with 10000 still active, and I can hear the sound from 10000. The other apps in the device still work well.
 
  EXPECTED BEHAVIOUR:
 The call with 10086 should be hold and the call with 10000 is connected.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
  10%
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Lingling Zhao]

I add some logs in the code, the errorName in startDial is NormalCallClearingError. Please see the attachments.

This issue happens in a high frequency.

Comment 2

[sync-1]

Attachment: logcat

Comment 3

[sync-1]

Attachment: picture for issue

Comment 4

[Lingling Zhao]

My further analysis in dialer app with the log:
After dialing the second call to 10000, there occurs error which name is NormalCallClearingError, here the call.state for 10000 is disconnected, it is not in telephony.calls, so is removed from handledCalls. And then in a very short time(may be 0.02s), the call.state for 10000 is dialing, 10000 is in telephony.calls, so it is added to  handledCalls again. 
For both 'remove' and 'add' action, the call-screen displays the corresponding information at almost the same time. It is just what the picture in attachment 8422242 [details] shows.

Line 5496: 12-31 19:00:49.389 E/GeckoConsole( 1170): Content JS LOG at app://communications.gaiamobile.org/dialer/js/telephony_helper.js:169 in errorCB: Unexpected error: NormalCallClearingError

Line 5150: 12-31 19:00:49.279 I/GeckoDump( 1170): zmm:evt.call.state=held
Line 5326: 12-31 19:00:49.339 I/GeckoDump( 1170): zmm:oncallschanged
Line 5327: 12-31 19:00:49.339 I/GeckoDump( 1170): zmm:call removecall
Line 5328: 12-31 19:00:49.339 I/GeckoDump( 1170): zmm:removecall
Line 5332: 12-31 19:00:49.339 I/GeckoDump( 1170): zmm:evt.call.state=resuming
Line 5333: 12-31 19:00:49.339 I/GeckoDump( 1170): zmm:evt.call.state=disconnected
Line 5350: 12-31 19:00:49.339 I/GeckoDump( 1170): zmm:remove
Line 5480: 12-31 19:00:49.379 I/GeckoDump( 1170): zmm:oncallschanged
Line 5487: 12-31 19:00:49.379 I/GeckoDump( 1170): zmm:updateCallsDisplay
Line 5494: 12-31 19:00:49.379 I/GeckoDump( 1170): zmm:updateCallsDisplay

But the log with key 'D/CALL_TRACKER_QC_B2G(  307): state :' does not have anything when 10000 disconnectd, I just find it for 10000 like the followings:
Line 5104: 12-31 19:00:49.269 D/CALL_TRACKER_QC_B2G(  307): state : 'DIALING', callIndex : -1,...
Line 5306: 12-31 19:00:49.329 D/CALL_TRACKER_QC_B2G(  307): state : 'DIALING', callIndex : 2,...
Line 5443: 12-31 19:00:49.369 D/CALL_TRACKER_QC_B2G(  307): state : 'DIALING', callIndex : 2,...
Line 5596: 12-31 19:00:51.359 D/CALL_TRACKER_QC_B2G(  307): state : 'ALERTING', callIndex : 2,...
Line 5727: 12-31 19:00:52.729 D/CALL_TRACKER_QC_B2G(  307): state : 'ACTIVE', callIndex : 2,...

Comment 5

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni Etienne

Hi Etienne -

Not sure if this is a dialer problem or a lower layer telephony problem, but could you help to check the attached log and the analysis in Comment#4 ? the behavior does look strange here

Thanks for your help

Comment 6

[Etienne Segonzac (:etienne)]

Can you try the patch from bug 1007598, there's a good chance it's our fix.

Comment 7

[Lingling Zhao]

Attachment: call_ended.png

Yes, dialer can continue to work when the error happens after I merge the patch. But there is another questions, as the attachment shows it displays Call Ended because the call indeed disconnected, but I think this screen may confuse the user.

So we need to find why the second call directly become call-ended and re-dial in so a short time.