Calling from memory index is very similar in functionality to dialing
the last called number. So we rename the functions so we can reuse them,
to deal with memory index calling. Function names now also reflect this
is for hfp.
Fix an error message from dbus about the path supplied not being valid.
Related to commit f58e7685b0
ofonod[19107]: src/voicecall.c:voicecall_dial_shortcut() check position
ofonod[19107]: src/voicecall.c:synthesize_outgoing_call() Registering new call: 1
process 19107: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_check_is_valid_path (*string_p)" failed in file ../../../dbus/dbus-message.c line 2759.
This is normally a bug in some application using the D-Bus library.
synthethize_outgoing_call was only used once from dial_handle_result.
So move all the logic of registering the call to D-Bus and adding it to
the voicecalls list to that function.
This will allow synthethize_outgoing_call to be used from other
callbacks where the dial callback is guaranteed to return before any
call state notifications, e.g. in the case of +BLDN.
call_status_to_string() is useful for debug output.
Change signature to contain enum call_status
Replace default case to get compiler warning when new enums added
When the voicecall atom is unregistered we remove all HFP support as
well but were supplying a zero as value to the emulator status
callbacks which caused the process to crash as we were dereferencing
the supplied value always and not respecting a zero as indicator to
reset.
Indicators should not be updated if:
- multiple separate calls are active at same time
- a conf call and a call are active at same time
- multiple separate calls are held at same time
- a conf call and a call are held at same time
- a conf call has call in active and held state
HFP does not implement HangupAll natively and most AGs do not support
releasing held calls by id. Work around this by using hangup active and
then dropping all held calls if no waiting calls exist. Otherwise
fall back to releasing calls by id.
If we have a single held call, then it should be possible to hang it up
with 'Hangup' even if active calls exist. Only if multiple held calls
or a waiting call exists should we disallow the request due to possible
side-effects.
Fix PTS test TP/TWC/BV-03-I [Call Waiting- Hold Active/Retrieve
Waiting Call or Held].
PTS test fails after receiving intermediate update of callheld indicator
with value 0 (no held call) before it receives update to value 1
(active and held calls). This is due to the non-atomic update of calls
status after call swap (moving first call to active state before moving
second one to hold state).
HFP 1.5 spec specifies that an update of callheld indicator to 1 should
be sent after AT+CHLD=2 command.
As oFono emulator sends +CIEV only if the indicator value changes, we
need to use an intermediate state for callheld indicator (2, all calls on
hold).
So, in case of multiple active calls, or an active call with an active
mutiparty call, force update of callheld indicator to 2.
It is not safe to call dial_request_user_cancel directly. This is
because there might be a situation where the SIM requested the calls to
be dropped first. If we're still executing the release_all_active
request and someone calls hangup -> crash.
Instead it is safer to throttle the hangup requests until the call is
actually dialing.
In similar fashion, we should not allow hanging up a specific call if a
dial request is active, unless that call is part of the SIM dial
request. Note that by default this is not known until the driver's dial
implementation returns and the call is in the dialing (or alerting /
connected) state.
Slava Monich
Philippe De Swert
Denis Kenzior
Philippe De Swert
Alexander Couzens
Marcel Holtmann
John Ernberg
Simon Fels
Philippe Nunes
Lucas De Marchi
Henrique Dante de Almeida
Frédéric Danis
Jeevaka Badrappan