From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============8394616871086057962=="
MIME-Version: 1.0
From: Jean-Christian de Rivaz <jc@eclis.ch>
Subject: Re: Polling CLCC error handling on Option modem (GTA04)
Date: Thu, 08 Mar 2012 22:54:59 +0100
Message-ID: <4F592AB3.2040206@eclis.ch>
In-Reply-To: <201203062047.48172.psonek2@seznam.cz>
List-Id: <ofono.ofono.org>
To: ofono@ofono.org

--===============8394616871086057962==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Le 06. 03. 12 21:47, Radek Polak a =C3=A9crit :
> Hi,
> first of all QtMoko [1] now supports ofono as another telephony backend [=
2]. We
> have also autogenerated qt bindings [3] which can be interesting also for
> other projects.
>
> But now the problem that has already been discussed. If you make call to =
GTA04
> with ofono running, it starts CLCC polling. After you hangup sometimes
> everything is ok and the call disappears:
>
> fonod[1027]: App:<  \r\n+CLCC: 1,1,4,0,0,"+420608828973",145\r\n\r\nOK\r\n
> ofonod[1027]: App:>  AT+CLCC\r
> ofonod[1027]: App:<  \r\nOK\r\n
> ofonod[1027]: src/voicecall.c:ofono_voicecall_disconnected() Got disconne=
ction
> event for id: 1, reason: 2
> ofonod[1027]: App:<  \r\n_OSIGQ: 18,0\r\n
> ofonod[1027]: src/network.c:ofono_netreg_strength_notify() strength 58
> ofonod[1027]: App:>  AT+CLCC\r
> ofonod[1027]: App:<  \r\nOK\r\n
>
> but sometimes the modem returns error:
>
> ofonod[1027]: App:<  \r\n+CLCC: 1,1,4,0,0,"+420608828973",145\r\n\r\nOK\r=
\n
> ofonod[1027]: App:>  AT+CLCC\r
> ofonod[1027]: App:<  \r\n+CME ERROR: 100\r\n
> ofonod[1027]: We are polling CLCC and received an error
> ofonod[1027]: All bets are off for call management
>
> and ofono never reports that the call is removed. The result is that GUI =
shows
> dialed call forever.
>
> I know that modem should not return error, but it would be nice to have at
> least some workaround. E.g. assume remote hangup or missed call.
>
> Or anyone has better ideas?

I have the feeling that this problem is common to many modems based on =

some Qualcomm chipset/firmware. A workaround will be a good idea to =

solve this issue, because throwing all those modems out of the window =

might be a genocide.

I observed on a SIMCOM modem that show the same issue, that the CLCC =

error is temporary. It seem to occurs when the CLCC command is proceeded =

by the modem at the same time that something change in the calling =

state. The next CLCC command will return the expected result. Can you =

observe that same behavior on your modem ?

Regards,

Jean-Christian

--===============8394616871086057962==--