Driver for modems that are accessed through the Android Radio Interface
Layer (RIL) for telephony, using the gril library. The driver is almost
feature complete with some exceptions, being CBS and SAT the most
prominent.
Co-authored-by: Tony Espy <espy@canonical.com>
Co-authored-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
Co-authored-by: Alfonso Sanchez-Beato <alfonso.sanchez-beato@canonical.com>
Co-authored-by: Islam Amer <islam.amer@jollamobile.com>
Co-authored-by: Jussi Kangas <jussi.kangas@tieto.com>
Co-authored-by: Juho Hämäläinen <juho.hamalainen@tieto.com>
Co-authored-by: Petri Takalokastari <petri.takalokastari@oss.tieto.com>
Co-authored-by: Jarko Poutiainen <Jarko.Poutiainen@oss.tieto.com>
Co-authored-by: Tommi Kenakkala <tommi.kenakkala@oss.tieto.com>
Co-authored-by: Miia Leinonen <miia.leinonen@oss.tieto.com>
Co-authored-by: Martti Piirainen <martti.piirainen@canonical.com>
Co-authored-by: You-Sheng Yang <vicamo.yang@canonical.com>
When a call is waitng, CCWA event is sent and call object
in state WAITING is created. on ReleaseAndAnswer it is
promoted to INCOMING and later to ACTIVE.
iPhones send an extra CCWA event when active call is ended.
This extra event is creating a second call object in state
WAITING. It is not possible to have two WAITING calls, but
previously waiting call was already promoted to INCOMING.
For a brief time we have two calls from the same number,
one INCOMING and one WAITING. Later WAITING one is removed.
As we cannot have a waiting and incoming call at the same
time, ignore CCWA when there is already an INCOMING call.
< \r\n+CIEV: 3,3\r\n
< \r\n+CIEV: 2,1\r\n
< \r\n+CIEV: 3,0\r\n
< \r\n+CCWA: "01234567890",129,1,"Me"\r\n
< \r\n+CIEV: 3,1\r\n
> AT+CLCC\r
< \r\n+CLCC: 1,0,0,0,0,"09876543210",129,"Me"\r\n
< \r\n+CLCC: 2,1,5,0,0,"01234567890",129,"Me"\r\n
< \r\nOK\r\n
< \r\n+CIEV: 2,0\r\n
< \r\n+CCWA: "01234567890",129,1,"Me"\r\n
< \r\n+CIEV: 2,1\r\n
< \r\n+CIEV: 3,0\r\n
> AT+CLCC\r
< \r\n+CLCC: 2,1,0,0,0,"01234567890",129,"Me"\r\n
< \r\nOK\r\n
It is possible for the phone to accept Dial request
but not actually dial. This leaves a voicecall object
in state 'dialling' that cannot be removed.
Proposed workaround is to trigger AT+CLCC when an error
is returned for Hangup. As the call is not on the list,
this would remove this hanging object and signal CallRemoved.
Windows Phone trace with this fix:
ofonod[273]: > ATD1;\r
ofonod[273]: < \r\nOK\r\n
ofonod[273]: src/voicecall.c:dial_handle_result() Registering new call: 1
ofonod[273]: < \r\n+CIEV: 5,4\r\n
ofonod[273]: src/network.c:ofono_netreg_strength_notify() strength 80
ofonod[273]: > AT+CHUP\r
ofonod[273]: < \r\nERROR\r\n
ofonod[273]: src/voicecall.c:generic_callback() command failed with error: Unknown error type
ofonod[273]: > AT+CLCC\r
ofonod[273]: < \r\nOK\r\n
ofonod[273]: src/voicecall.c:ofono_voicecall_disconnected() Got disconnection event for id: 1, reason: 2
If there is more then one active or held call, we are in mpty calls.
We won't get indicator update if any of them is released by CHLD=1x.
So we have to poll it.
A periodic CLCC polling is started when there is an ongoing multiparty
call and a new call appears in the system. A simple way to reproduce
the crashing scenario is:
1. Place a call.
2. Place a second call.
3. Create a multiparty call with both calls.
4. Place a third call (incoming or outgoing does not matter).
5. Disconnect HFP from the modem.
Within the function ciev_callheld_notify, the AT+CLCC command is also
invoked, thus a new cyclic CLCC polling is started, and it overwrites
the timer resource identifier stored in voicecall_data.clcc_source.
This means that there are several timers doing the CLCC polling, but
only one of those is under control, i.e. it can be removed through its
source identifier, hence a timer source leak.
This has a fatal consequence when the HFP modem is disconnected. The
function hfp_voicecall_remove stops the timer that is under control
before freeing the voicecall_data struct. However there are other timers
that are still active and will execute its handler poll_clcc afterwards.
Inside poll_clcc the driver_data is accessed, which is already NULL.
A solution for this is to avoid starting a CLCC polling if there is
already one active, i.e. clcc_source is not 0. By doing this the
uncontrolled timers will not cycle forever.
According to the standard "3GPP 27.007 v6.8.0" Appendix C.2.11,
when sending multiple DTMF characters, these must go in individual
+VTS commands for each tone. This adopts the AT modem approach.
Before: AT+VTS=1234\r
After: AT+VTS=1;+VTS=2;+VTS=3;+VTS=4\r
The affected call types for +CHUP were set to only ACTIVE calls.
Instead the affected set should include INCOMING, DIALING, ALERTING and
ACTIVE calls.
Thanks to Ionut Dediu for the diagnosing and reporting this issue.
Tony Espy
Kuba Pawlak
Alex J Lennon
Denis Kenzior
Cedric Jehasse
Philip Paeps
Sergio Checa Blanco
Andrew Earl
Krzysztof Wilk
Anthony Viallard