Hi Denis,
Denis Kenzior wrote, On 31.01.2013 05:09:
Hi Timo,
On 01/28/2013 04:13 AM, Timo Mueller wrote:
From: Timo Mueller<[email protected]>
With a call being active, placing a second call on the AG device will
lead to the active call being put on hold. During the transition some
phones do not update the list of current calls. This leads to an +CLCC
response that does not contain the new outgoing call, even though an
outgoing callsetup was reported.
The list will be updated once the active call was put on hold and
callheld=2 is reported. In this case the list has to be requested
again (AT+CLCC).
AT sequence that exhibited the failure (AG device was a Nokia N9
having an active outgoing call and placing a second outgoing call)
Ugh.
<snip>
@@ -1072,6 +1074,14 @@ static void ciev_callheld_notify(struct
ofono_voicecall *vc,
call->status = CALL_STATUS_HELD;
ofono_voicecall_notify(vc, call);
}
+
+ if (callsetup == 2 || callsetup == 3) {
+ dialing = find_dialing(vd->calls);
+
+ if (dialing == NULL)
+ g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
+ clcc_poll_cb, vc, NULL);
+ }
} else if (callheld == 1) {
if (vd->clcc_source)
g_source_remove(vd->clcc_source);
I'm seeing reports of too many devices doing too many weird things, and
if we change the core logic for each and every one then the code becomes
a huge mess quickly. It would be hard to validate or regression test it
without massive investment in automated interoperability testing.
Marcel and I spoke briefly about this and our belief is that we need to
introduce manufacturer specific quirks to HFP drivers instead of trying
to solve this generically.
BlueZ should be able to provide us enough information about the remote
device for us to make a fairly good guess as to the manufacturer /
version. Additional details can be queried by manufacturer specific
commands (e.g. in the case of iOS). That should be enough for us to
simply set the vendor / quirk ID and take appropriate action in the driver.
We can always fall back to strict spec compliant behavior by default if
the manufacturer quirks cannot be determined. What do you think?
I agree, that the core logic shouldn't be polluted with phone specific
workarounds. This is especially true when the quirks somehow interfere
or modify the standard path. Having said this, I'd consider this fix
general enough to justify it's integration in the standard driver, since
the policy makes sense for any phone (mis)behaving this way, keeping the
phone specific quirks to an absolute minimum.
I know that the N9 is the only phone that has seen this problem so far,
but the problem will occur with every phone that doesn't "atomically"
change the CLCC list the moment it reports an indicator change (+CIEV).
As described in the commit message the phone already told the HF that it
has set up an outgoing call (or that it's already alerting). The only
thing missing is the detailed information about the call, which is
retrieved using the AT+CLCC request.
So in this case I think it's valid to generally try to fill in the
missing information by issuing another AT+CLCC request. Otherwise the
call will be alerting and although the phone has reported all indicator
changes to oFono, we won't be able to reasonably control it from HF side.
Regards,
-Denis
Best regards,
Timo
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
