[PATCH 3/4] Fix: Avoid release dialing call when call is 0

[PATCH 3/4] Fix: Avoid release dialing call when call is 0

[Zhenhua Zhang]

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

If +CIEV call goes to 0, we may have another dialing call. We
should not release this dialing call when call=0.
---
 drivers/hfpmodem/voicecall.c |   23 +++++++++++++++++++++--
 1 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index d9c3c2a..53d4fd1 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -590,10 +590,11 @@ static void ciev_call_notify(struct
ofono_voicecall *vc,
 	{
 		GSList *waiting;
 		GSList *incoming;
+		GSList *dialing;
 
 		/* If call goes to 0, then we have no held or active calls
 		 * in the system.  The waiting calls are promoted to incoming
-		 * calls
+		 * calls and dialing call is kept.
 		 */
 		waiting = g_slist_find_custom(vd->calls,
 					GINT_TO_POINTER(CALL_STATUS_WAITING),
@@ -612,8 +613,26 @@ static void ciev_call_notify(struct ofono_voicecall
*vc,
 		if (incoming)
 			vd->calls = g_slist_remove_link(vd->calls, incoming);
 
+		/* The dialing call should be kept dialing */
+		dialing = g_slist_find_custom(vd->calls,
+					GINT_TO_POINTER(CALL_STATUS_DIALING),
+					at_util_call_compare_by_status);
+
+		if (!dialing)
+			dialing = g_slist_find_custom(vd->calls,
+						GINT_TO_POINTER(
+							CALL_STATUS_ALERTING),
+						at_util_call_compare_by_status);
+
+		if (dialing)
+			vd->calls = g_slist_remove_link(vd->calls, dialing);
+
 		release_all_calls(vc);
-		vd->calls = incoming;
+
+		if (incoming)
+			vd->calls = incoming;
+		else if (dialing)
+			vd->calls = dialing;
 
 		break;
 	}
-- 
1.6.2.5

Re: [PATCH 3/4] Fix: Avoid release dialing call when call is 0

[Zhenhua Zhang]

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

Hi

On Mon, 2009-11-16 at 22:12 +0800, Zhenhua Zhang wrote:
> If +CIEV call goes to 0, we may have another dialing call. We
> should not release this dialing call when call=0.
> ---

Here's one example to explain how it could happen. we have two
calls: active A and dialing B. If A is released by remote, B
should not be released. But now we released both of them at
 ciev_call_notify().

Below is the detailed log. A is 10086 and B is 61167086.
--------
ofonod[4508]: > ATD61167086;\r
ofonod[4508]: < \r\nOK\r\n
ofonod[4508]: atd_cb got result: 1
ofonod[4508]: Final response: OK
ofonod[4508]: < \r\n+CIEV: 3,2\r\n
ofonod[4508]: > AT+CLCC\r
ofonod[4508]: < \r\n+CIEV: 7,1\r\n
ofonod[4508]: Got a voicecall event, status: 1, id: 1, number: 10086
ofonod[4508]: Found call with id: 1
ofonod[4508]: < \r\n+CLCC: 1,0,1,0,0,"10086",129,"10086 (Mobile)"\r\n
ofonod[4508]: < \r\n+CLCC: 2,0,2,0,0,"61167086",129\r\n
ofonod[4508]: < \r\nOK\r\n
ofonod[4508]: sync_dialing_cb got result: 1
ofonod[4508]: Final response: OK
ofonod[4508]: Response line: +CLCC: 1,0,1,0,0,"10086",129,"10086
(Mobile)"
ofonod[4508]: Response line: +CLCC: 2,0,2,0,0,"61167086",129
ofonod[4508]: Got a voicecall event, status: 2, id: 2, number: 61167086
ofonod[4508]: Did not find a call with id: 2
ofonod[4508]: < \r\n+CIEV: 3,3\r\n
ofonod[4508]: Got a voicecall event, status: 3, id: 2, number: 61167086
ofonod[4508]: Found call with id: 2
ofonod[4508]: < \r\n+CIEV: 2,0\r\n
ofonod[4508]: Got disconnection event for id: 1, reason: 2
ofonod[4508]: Got disconnection event for id: 2, reason: 2
ofonod[4508]: < \r\n+CIEV: 7,0\r\n
ofonod[4508]: > AT+CLCC\r
ofonod[4508]: < \r\n+CLCC: 2,0,3,0,0,"61167086",129\r\n
ofonod[4508]: < \r\nOK\r\n
ofonod[4508]: clcc_poll_cb got result: 1
ofonod[4508]: Final response: OK
ofonod[4508]: Response line: +CLCC: 2,0,3,0,0,"61167086",129
ofonod[4508]: Got a voicecall event, status: 3, id: 2, number: 61167086
ofonod[4508]: Did not find a call with id: 2
ofonod[4508]: Warning: Call id and internally tracked id do not
correspond

Re: [PATCH 3/4] Fix: Avoid release dialing call when call is 0

[Denis Kenzior]

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

Hi Zhenhua,

> If +CIEV call goes to 0, we may have another dialing call. We
> should not release this dialing call when call=0.

Yes, you're absolutely correct.

I fixed it slightly differently.  The main issue was that it is possible to have 
a dialing and a waiting call under some circumstances.  Neither the current 
code nor your fix handled that case.  The code is much simpler now as well.  
Let me know if the issue persists.

Regards,
-Denis