[QtExtended] missed call trace (was: latest andy-tracking kernel)

Franky Van Liedekerke liedekef at telenet.be
Wed Apr 15 00:43:56 CEST 2009

On Tue, 14 Apr 2009 23:25:56 +0200
Franky Van Liedekerke <liedekef at telenet.be> wrote:

> On Tue, 14 Apr 2009 22:30:28 +0200
> Sander van Grieken <sander at 3v8.net> wrote:
> > On Tuesday 14 April 2009 21:54:53 Franky Van Liedekerke wrote:
> > > Maybe the latest version is ok again, but it is IMPOSSIBLE TO TEST
> > > since ssh no longer works. Surely somebody must notice this, or is
> > > nobody even using these images?
> > 
> > Yeah I noticed too, but I assumed I b0rked my build system, since I
> > tried to use the SHR overlay manually.. also, X didn't start
> > anymore, that's when I noticed SSH didn't work.
> > 
> > but, while waiting for the entire rebuild to finish, I'm taking a
> > look at the commits since April 4 :)
> well, I don't know, but reverting to that kernel+rootf fixed the
> incoming SMS when suspended thing.
> But now the whole missed-call comes flying back to me: whenever I
> answer a call, the second after I pressed "answer", a new call
> notification pops up saying I have the same incoming call.
> Seems like a timing issue to me ... propably something in
> qmodemcallprovider.cpp that should be redefined in vendor_neo.cpp
> Franky

ok, for those curious: I've put online a AT-listing of a missed call:

The scenario is this: call the device from another line, answer the
call and watch a notification for a second call arrive (sometimes).
The AT commands in the text file are of course the results of both
calls, so it can be a bit confusing. Although the AT-call "ATA" should
give you a hint that the device in the end thinks there is only one
active call (otherwise it would be AT+CHLD=2).

I think the cause of the problems lies in the function
void QModemCallProvider::clccIncoming()
in the file src/libraries/qtopiaphonemodem/qmodemcallprovider.cpp

Specifically this part seems to be the culprit:

    if ( callType.isEmpty() ) {
        // We could not determine the call type, so the incoming call
        // has probably disappeared.  Flag it as a missed voice call.
        d->incomingCallType = "Voice";      // No tr
    } else {

This part makes sure that for a call that can't be identified, the call
gets announced and then flagged as being missed, exactly what I see in
the logfile.
Now I don't get this: why flag an dissapeared call of unknown type as
voice and missed call?
From what I can see, this code should be:

    if ( callType.isEmpty() ) {
        // We could not determine the call type, so the incoming call
        // has probably disappeared. Ignore it.
    } else {

Any comments on this?
Ok, the fact that the modem sends an extra RING after the call is
accepted is probably because it's a bit slow sometimes (or the RING
arrives a bit too slow).


More information about the community mailing list