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.
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."
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"
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.
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.