An issue with iPhone 5C iOS 9.2 triggers desynchronization in call
states. When an active call is put on hold and another call arrives,
it is in WAITING state. It should be possible to answer it by issuing
AT+CHLD=2 but the phone changes its state to INCOMING so ATA should be
used. This change is advertised by sending callheld:2 event, but it is
not handled. This event can be used to trigger CLCC poll to synchronize
call states.
+CIEV: 3,1 <- first call arrives
AT+CLCC
+CLCC: 1,1,4,0,0,"01234567890",129
OK
RING
+CLIP: "01234567890",129
ATA
OK
+CIEV: 2,1
+CIEV: 3,0.
AT+CHLD=2.$ <- first call is put on hold
OK
+CIEV: 7,2 <- notification confirming that call #1 is on hold
+CCWA: "09876543210",129,1 <- second call arrives
+CIEV: 7,2
+CIEV: 3,1
AT+CLCC
+CLCC: 1,1,1,0,0,"01234567890",129
+CLCC: 2,1,5,0,0,"09876543210",129 <- new call is still in WAITING state
OK
+CIEV: 7,2 <- phone iternally promotes WAITING call to INCOMING
AT+CHLD=2 <- there is no WAITING call anymore, ATA should be used
+CME ERROR:3
When issuing a Scan() in poor reception while attached to an operator it's
fully possible to get no results, which causes the attached operator to be
cleaned up. In certain scenarios this would cause a use-after-free as there
are still references to this operator.
Transfer the attached operator to the new list regardless of removal caused
by the Scan() results.
This matches the behavior described by the documentation the signal
value returned by the code. This was causing a headache when using
stricter D-Bus wrappers like dbus-c++.
In situations where location changes rapidly, a use-after-free condition
can occur. What happens is that the timeout leaks and then the cbs
struct with the callback is cleaned up, resulting in a SIGSEGV when the
callback occurs from the glib loop.
The return value from a RIL_REQUEST_GET_FACILITY_LOCK
is the TS 27.007 service class bit vector of services
for the specified barring facility. The value canf be
zero, which indicates "disabled for all".
During the re-factoring of rilmodem's sim atom
messaging code, the sim_status_cb function's
RIL tracing code was converted to DBG calls.
This change adds the same prefix to DBG/trace
calls when a single message's parameters span
more than one DBG call. This makes it easier
to filter out trace messages when looking at a
log file.