Ticket #906 (closed defect: fixed)

Opened 12 years ago

Last modified 11 years ago

Dialer fails to cancel out-going calls

Reported by: Tuukka.Hastrup@… Owned by: tick@…
Priority: high Milestone:
Component: gsmd Version: current svn head
Severity: critical Keywords:
Cc: buglog@…, hrw@…, balrogg@…, tick@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

Steps:

  1. Initiate a call in the dialer.
  2. Press the hang-up button before the call is connected.

Result:
GUI returns to the keypad interface but the call continues in the background.

Expected result:
The call is cancelled and GUI returns to the keypad interface.

This may very well need a change in gsmd/libgsmd, since ATH doesn't get through
in this state.

Change History

comment:1 Changed 12 years ago by thomas@…

Confirmed, although I think this has worked before and there hasn't been any
changes in the dialer that might affect it. What investigation did you do that
causes you to think it may be a problem in gsmd/libgsmd?

comment:2 Changed 12 years ago by Tuukka.Hastrup@…

I place a call using libgsmd-tool --mode atcmd:

ATH
STR=`ATH'
RSTR=`OK'
ATD0405922923;
STR=`ATD0405922923;'
EVENT: Outgoing Call Progress: UNKNOWN
EVENT: Outgoing Call Progress: PROCEED
EVENT: Outgoing Call Progress: SYNC
EVENT: Outgoing Call Progress: PROGRESS
EVENT: Outgoing Call Progress: ALERT
ATH

Now nothing happens until I answer or deny the call on the receiving side.

EVENT: Outgoing Call Progress: DISCONNECT
RSTR=`BUSY'
STR=`ATH'
EVENT: Outgoing Call Progress: RELEASE
RSTR=`OK'

Looking at current gsmd/atcmd.c, "/* we only send one cmd at the moment */",
which is in line with ATH going through only after ATD has finished with the
result "BUSY".

comment:3 Changed 12 years ago by cesarb@…

That "we only send one cmd at the moment" was wrong; due to a bug, it sometimes
sent more than one comment at a time (as I found out while investigating bug
766). There are some patches in openembedded (but not on the upstream openmoko
SVN) which changed that code path (I no longer can reproduce the bug I
originally reported as #766), so the bug might have been fixed by accident.

comment:4 Changed 12 years ago by cesarb@…

  • Cc hrw@… added

comment:5 Changed 12 years ago by cesarb@…

* Bug 925 has been marked as a duplicate of this bug. *

comment:6 Changed 12 years ago by Tuukka.Hastrup@…

  • dependson set to 928

OK, discussed this with Cesar on IRC and did some testing to find possible fixes.

As he writes above, this bug might have started showing when #766 was fixed
(partially). I noticed the COLP setting also affects whether this bug is seen.

There doesn't seem to be anything the dialer can do about this at the moment, so
blocking on gsmd #928, which ever way that will be solved.

comment:7 Changed 12 years ago by balrogg@…

  • Cc balrogg@… added

comment:8 Changed 12 years ago by thomas@…

  • Owner changed from thomas@… to laforge@…
  • Component changed from openmoko-dialer to gsmd

Moving to GSMD as this is not a Dialer bug.

comment:9 Changed 12 years ago by tick@…

  • Cc tick@… added

comment:10 Changed 12 years ago by tick@…

  • Owner changed from laforge@… to tick@…

comment:11 Changed 12 years ago by tick@…

  • Status changed from new to assigned

comment:12 Changed 11 years ago by tick@…

  • Status changed from assigned to closed
  • Resolution set to fixed

I want to switch this issue to fixed.
As ##928

Note: See TracTickets for help on using tickets.