[Gta04-owner] Polling CLCC error handling on Option modem (GTA04)

[Dr. H. Nikolaus Schaller]

Am 06.03.2012 um 21:47 schrieb Radek Polak:

> 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 disconnection 
> 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

I think this are all the same symptoms of the same bug. NO CARRIER being
reported on another port and serial interface disappearing.

What I could imagine that the modem tries to report the end of the call
but due to this bug, the communication thread within the real-time-os that
controls the interface crashes and a watchdog timer resets this resulting in
this 100 error code (which means "unknown error").

> 
> 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?

Well, it could just ignore the "100" error and retry polling after a short delay?

Or does the modem really get inoperable? In that case it could
issue an AT_ORESET and reinitialize.

I know this is not nice, but appears the easiest way to work around
the problem.

@Radek: is it possible to manually contact the AT interface in this state
and try if it is still operational and another AT+CLCC would succeed?

BR,
Nikolaus