[PATCH] Delay AT+CLCC request after setup of an outgoing call

[PATCH] Delay AT+CLCC request after setup of an outgoing call

[mail]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

From: Timo Mueller <timo.mueller@bmw-carit.de>

Hi,

this fixes an issue we've been experiencing with the Nokia N9. When
placing an outgoing call from the N9 (AG device) the responded list
does not containt the new outgoing call as the N9 did not update the
list yet.
I tried reqesting the list a second time right after the first request
and the response always contained the call. In conclusion I added a
delay to the first request to give the AG device some time to update
the list before requesting it.

Best regards,
Timo

Timo Mueller (1):
  hfpmodem: Delay AT+CLCC request after outgoing callsetup

 drivers/hfpmodem/voicecall.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

-- 
1.7.11.7

[PATCH] hfpmodem: Delay AT+CLCC request after outgoing callsetup

[mail]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

From: Timo Mueller <timo.mueller@bmw-carit.de>

Currently the list of current calls is requested right after an
outgoing callsetup has been reported by the AG device. If the AG
device updates the list after reporting the callsetup the +CLCC
response may not contain the new call and it is not registered
with oFono.

AT sequence that exhibited the failure (AG device was a Nokia N9
placing an outgoing call)

< \r\n+CIEV: 5,2\r\n
> AT+CLCC\r
< \r\nOK\r\n
< \r\n+VGS=7\r\n
< \r\n+VGM=7\r\n
< \r\n+CIEV: 5,3\r\n
< \r\n+CIEV: 4,1\r\n
< \r\n+CIEV: 5,0\r\n
---
 drivers/hfpmodem/voicecall.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index 505601c..c7c5f45 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -912,8 +912,11 @@ static void ciev_callsetup_notify(struct ofono_voicecall *vc,
 		 * from HF: query and sync the phone number.
 		 * from AG: query and create call.
 		 */
-		g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
-				clcc_poll_cb, vc, NULL);
+		if (vd->clcc_source)
+			g_source_remove(vd->clcc_source);
+
+		vd->clcc_source = g_timeout_add(POLL_CLCC_DELAY,
+							poll_clcc, vc);
 		break;
 
 	case 3:
-- 
1.7.11.7

Re: [PATCH] hfpmodem: Delay AT+CLCC request after outgoing callsetup

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

Hi Timo,

On 01/11/2013 07:00 AM, mail(a)timomueller.eu wrote:
> From: Timo Mueller<timo.mueller@bmw-carit.de>
>
> Currently the list of current calls is requested right after an
> outgoing callsetup has been reported by the AG device. If the AG
> device updates the list after reporting the callsetup the +CLCC
> response may not contain the new call and it is not registered
> with oFono.
>
> AT sequence that exhibited the failure (AG device was a Nokia N9
> placing an outgoing call)
>
> <  \r\n+CIEV: 5,2\r\n

So here it tells us that the callsetup is 2 (e.g. dialing)

>> AT+CLCC\r
> <  \r\nOK\r\n

And then it tells us "There are no calls to see here..."

Big. Fail. ;)

> <  \r\n+VGS=7\r\n
> <  \r\n+VGM=7\r\n
> <  \r\n+CIEV: 5,3\r\n
> <  \r\n+CIEV: 4,1\r\n
> <  \r\n+CIEV: 5,0\r\n
> ---
>   drivers/hfpmodem/voicecall.c | 7 +++++--
>   1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
> index 505601c..c7c5f45 100644
> --- a/drivers/hfpmodem/voicecall.c
> +++ b/drivers/hfpmodem/voicecall.c
> @@ -912,8 +912,11 @@ static void ciev_callsetup_notify(struct ofono_voicecall *vc,
>   		 * from HF: query and sync the phone number.
>   		 * from AG: query and create call.
>   		 */
> -		g_at_chat_send(vd->chat, "AT+CLCC", clcc_prefix,
> -				clcc_poll_cb, vc, NULL);
> +		if (vd->clcc_source)
> +			g_source_remove(vd->clcc_source);
> +
> +		vd->clcc_source = g_timeout_add(POLL_CLCC_DELAY,
> +							poll_clcc, vc);

Actually I really don't like this, you are delaying the call detection 
for all devices (even good ones) because of one broken one.

I'd rather we request the CLCC immediately, but set a flag to retry the 
CLCC after a timeout in case the call list is not what we expected.

>   		break;
>
>   	case 3:

Regards,
-Denis