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.
The SIM900 module from SIMCOM does have a AT+CGDATA command.
However, it is not possible to make a ppp connection when CGDATA
has been used to bring up the gprs context.
This patch adds a quirk that uses the alternative ATD*99***<cid>#
command instead.
Before, the AT+BAC command was being sent with fixed information,
now we send the command (that inform the AG of the codecs supported by
the HF) with the codecs supported by the registered Handsfree Audio
Agent.
This patch fixes segmentation fault when the network registration
watch is called without being initialized. CIEV GAtChat callback can
be called before ofono_netreg_register().
==15101== Invalid read of size 8
==15101== at 0x492B56: ofono_netreg_register (network.c:2073)
==15101== by 0x47245E: hfp_netreg_probe (network-registration.c:311)
==15101== by 0x492A8D: ofono_netreg_create (network.c:1881)
==15101== by 0x4849D5: hfp_pre_sim (hfp_hf_bluez5.c:288)
==15101== by 0x48C486: ofono_modem_set_powered (modem.c:1194)
==15101== by 0x484E9D: slc_established (hfp_hf_bluez5.c:85)
==15101== by 0x4702AD: chld_cb (slc.c:147)
==15101== by 0x440457: at_chat_finish_command (gatchat.c:461)
==15101== by 0x44109F: new_bytes (gatchat.c:532)
==15101== by 0x4433B7: received_data (gatio.c:122)
==15101== by 0x3CBAA47824: g_main_context_dispatch (gmain.c:2539)
==15101== by 0x3CBAA47B57: g_main_context_iterate.isra.23
(gmain.c:3146)
==15101== Address 0x18 is not stack'd, malloc'd or (recently) free'd
Some phones do not send the corresponding call state update (+CIEV)
after a successful release-and-swap operation (AT+CHLD=1).
This has been observed with a Nokia 500, while testing ReleaseAndSwap()
while an active and a held call exist:
ofonod[20414]: > AT+CLCC\r
ofonod[20414]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20414]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20414]: < \r\nOK\r\n
ofonod[20414]: > AT+CHLD=1\r
ofonod[20414]: < \r\nOK\r\n
After this, no +CIEV is received, but the call has been hung up.
The proposed approach to solve this consists of using AT+CLCC, unless
a call release has been received within a specific time period.
The result fixes the problem as can be seen below:
ofonod[20847]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CHLD=1\r
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CLCC\r
ofonod[20847]: < \r\n+CLCC: 1,0,0,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: < \r\n+CIEV: 5,2\r\n
ofonod[20847]: < \r\n+CIEV: 5,0\r\n
While processing the result of AT+CLCC, process the differences in a way
that disconnections are reported first, then call state changes and
finally new calls.
The goal is to avoid unnecessary transitional states such as two active
calls existing at the same time.
Right now, only the mandatory CVSD codec is supported. The mSBC
mandatory codec is "temporarily" not supported.
The spec alows this, HFP 1.6 Spec Section 4.34.1 page 92: "If wide band
speech is supported then the mandatory codec (mSBC) shall be included
unless it is temporarily unavailable."
Especially for Telit HE910 it is not enough to wait for
entering a PIN code.
If we do not wait for #QSS: 3, subsequent commands,
like +CMER will report SIM BUSY and the network registration
atom will be removed as a consequence.
If device probe and removal happen in short succession, it's possible
that the idle handler registered in the probe function doesn't run before
the device is removed. In this case, the idle handler needs to be
unregistered so that it does not run and try to access the data that's
destroyed during the removal.
We might have mis-interpreted how 27.007 intends for CBS to work. After
studying the implementation notes of the IMC 6260 modem, the spec intent
made a little bit more sense.
During STK Set Up Call, we have modem-originated calls that do not go
through the core 'Dial' method. Make sure the calls are still detected
in this case.
Encountered a problem of CME ERROR 14: SIM busy on Alcatel and Huawei modem.
The Huawei modem has a ^SIMST unsollicited sim state indication, but not all
Huawei modems support this.
So poll the SIM state, as was already done for ZTE modems.
The Wavecom Q2XXX support broke in commit 72ce19bf3e.
This is because at_cpin_cb called decode_at_error with final and not
with OK. This lead to an error being set in the error variable and the
new code returns early when an error is set.
The addition of the terminator in at_sim_probe for Wavecom broke in
git commit ac524be99f because
terminators can not be added on cloned chats.
Move the addition of the terminator from the atmodem to the wavecom
plugin. Use the same terminator for Q2XXX and the normal Wavecom
class. The WAVECOM terminator has been tested on a Q2XXX modem.
Apply the CPIN quirk for both WAVECOM and WAVECOM_Q2XXX inside the
sim.c file. Introduce needs_wavecom_sim_quirk to handle it for
WAVECOM and WAVECOM_Q2XXX.
The existing wavecom driver in tree slightly differs from these
modems. Thus, it doesn't work work with them. We (the osmocom
team) use these Wavecom Q2403/Q2686 modems in our testbed.
Some modems might see an interim +CREG: or +CGREG: notification when
querying the supported modes.
Aux: > AT+CFUN=1\r
Aux: < \r\nOK\r\n
Aux: > AT+CREG=?\r
Aux: < \r\n+CREG: 2\r\n
Aux: < \r\n+CREG: (0-2)\r\nOK\r\n
Unable to initialize Network Registration
To make this work, skip to the first line with an actual range value.
We encountered the problem of CME ERROR 14: SIM busy on ZTE modems.
ZTE modems don't use SIM notification to check SIM state.
We poll SIM ready state before confirming PIN is entered.
A call that moves from the dialing to active state before the +CLCC response
will not properly be added as a voicecall. This is because the dialing callback
was using simplified handling and only looked for calls in the dialing or
alerting state.
AT sequence that exhibited the failure (AG device was an iPhone accessing
visual voicemail):
> +CIND: ("service",(0-1)),("call",(0-1)),("callsetup",(0-3)),
("battchg",(0-5)),("signal",(0-5)),("roam",(0-1)),("callheld",(0-2))
...
> +CIEV: 3,2
< AT+CLCC
> +CIEV: 2,1
> +CIEV: 3,0
> +CLCC: 1,0,0,0,0,"**21153**",129,"Voicemail"
Voice output serial port is enabled on some Huawei models (e.g. E169)
without problems, but for example on E173u-2 it is never enabled
during an incoming call. There might also be other Huawei models
having the same issue.
I traced the issue down to "^DDSETEX" AT command, which is used
to notify the device to start streaming audio. It seems that Ofono
sends this command too early on incoming calls. The command should
always be sent *after* the dial "D" or answer "A" command. The patch
fixes this behavior and afterwards voice will also work on E173u-2.
Some phones report CLCC calls with out-of-range info. E.g. call index
being 0 (it is 1 based according to 27.007) and call states being
reported as '6' (valid call states are 0-5.)
Use AT+SPIC for obtaining retries remaining for SIM PIN / PUK
AT+SPIC Retries Remaining to Input SIM PIN/PUK
+SPIC: <pin1>,<pin2>,<puk1>,<puk2>
Parameters
<pin1> Times remained to input chv1
<pin2> Times remained to input chv2
<puk1> Times remained to input puk1
<puk2> Times remained to input puk2
It seems the that XCIEV notification actually returns results from XCSQ
and not the described range 0-7. This makes this notification rather
useless to report signal strength.
Emergency Numbers can only be digits, so there's no point to use the
'Hammer of Thor' that is g_utf8_validate when a much simpler function
will do the job just as well.
XLEMA reports emergency numbers that are hardcoded (e.g. 112 and 911)
and that are already read from EFecc. The additional emergency numbers
we are interested in should only come from the NVM or the network NITZ
update.
This might be either a modem firmware bug or the SIM card is provisioned
really badly, but the last entry contains garbage characters.
ofonod[20620]: Voice: < \r\n+XLEMA: 1,9,"112",,1\r\n\r\n+XLEMA: 2,9,"911",,1\r\n\r\n+XLEMA: 3,9,"000",57,1\r\n\r\n+XLEMA: 4,9,"08",49,1\r\n\r\n+XLEMA: 5,9,"112",49,1\r\n\r\n+XLEMA: 6,9,"118",0,1\r\n\r\n+XLEMA: 7,9,"119",0,1\r\n\r\n+XLEMA: 8,9,"911",0,1\r\n\r\n+XLEMA: 9,9,"999\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377",0,1\r\n
Fix this by just validating the string and cutting off once an invalid
character is found.
The Huawei devices support a special 8-bit PDU mode for USSD that is
by default selected (AT^USSDMODE=1). It avoids the complicated logic
for character set selection and conversion.
This driver will be used by CDMA modems to support PIN
management and IMSI retreival.
EF entries for CDMA modems cannot be implemented without
manufacturers specifications.
The voice call support of the Qualcomm MSM based modems does not report
NO CARRIER, NO ANSWER or BUSY unsolicited notifications. So keep polling
for call state changes via AT+CLCC even during an active call.
In case of Qualcomm MSM based modems, AT+COLP=0 needs to be used to make
ATD<number>; return right away. Otherwise it only returns once the remote
party accepted or rejected the call.
According to the HFP specification, inband ringing will be enabled by
default if the AG supports it. This setting could later be changed by
the unsolicited result code +BSIR.
Before the phonebook is ready, the SIM card needs certain amount of
time. Something between 20-30 seconds in general. So if the modem
returns an error indicating the SIM is busy, then try again in
regular intervals.
Callheld move from 1 (active and held calls) to 2 (all calls on hold) may
result of:
- active call has been dropped by remote,
- an intermediate state during a call swap which will be followed by a
move back to 1.
So, wait a little before checking calls state.
The result of the capabilities command is currently not used to identify
GSM support or not. However for debugging purposes the information are
part of the AT command debug log now.
The same enum name SMS_ROUTE_DEFAULT has different constants in
different modem API versions. This was causing "invalid parameter"
errors with some modems.
In case of call creation failure modem may return a valid call id in
order to send CALL_SERVICE_DENIED_IND which we do not handle.
Fixes MeeGo bug#15855.