Open Source Telephony
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [RFC] STE-driver: Terminating voice call in state DIALING/ALERTING.
Date: Thu, 05 Aug 2010 14:19:01 -0500	[thread overview]
Message-ID: <4C5B0EA5.80806@gmail.com> (raw)
In-Reply-To: <AANLkTinPx07H7LUBiy6SGYRCX7nWCaLUUMwv3wmSjPST@mail.gmail.com>

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

Hi Sjur,

On 08/05/2010 02:04 PM, Sjur Brændeland wrote:
> Hi Denis,
> 
> Denis Kenzior wrote:
>>> I'm picking up a really old thread here...
>> Yes a really old thread ;)
> Better late than never, right? :-)
> 
> ...

Definitely :)  I'm very glad you brought this back up.

>>> However, I think we can solve this even simpler if we just
>>> call hangup for any ALERTING/DIALING call..
>> This is a real gray area.  On some devices this will work, on others it
>> might have un-intentional consequences.  At least on the calypso,
>> sending CHUP/ATH will terminate all calls not in the WAITING state.
> 
> Ok, so we should go forward with this proposal then.
> I'll try to send a new RFC within the next couple of days.
> 
> My initial intention here was not to submit patches
> on src/voicecall.c, but to make sure I understood your proposal properly.
> Let me know how you think we should go forward with this, as this
> impacts all drivers/*/voicecall.c
> 

Yes, I think this definitely makes sense.  There might be some other
modems we don't cover properly (some don't allow HELD calls to be
terminated using CHLD=1X), but we cross that bridge when we come to it.

>>> -	 if (call->status == CALL_STATUS_INCOMING) {
>>> +	 if (vc->driver->hangup_active && call->status == CALL_STATUS_INCOMING) {
>>
>> You're breaking the logic somewhat here.  If the call is INCOMING, we
>> shouldn't skip the rest of the block if hangup_active is not implemented.
>>
>>> 		 if (vc->driver->hangup == NULL)
>>> 			 return __ofono_error_not_implemented(msg);
>>>
>>> 		 vc->pending = dbus_message_ref(msg);
>>> -		 vc->driver->hangup(vc, generic_callback, vc);
>>> +		 vc->driver->hangup_active(vc, generic_callback, vc);
>>>
>>> 		 return NULL;
>>> 	 }
>>
>> Here we need to check whether hangup_active or hangup_all are
>> implemented. If both are, then prefer hangup_all.  This would make it
>> easier to keep compatibility with current drivers.
> 
> Did you have something like this in mind then:
> 
> 	if (call->status == CALL_STATUS_INCOMING) {
> 		vc->pending = dbus_message_ref(msg);
> 		if (vc->driver->hangup_all)
> 			vc->driver->hangup_all(vc, generic_callback, vc);
> 		else if (vc->driver->hangup_active)
> 			vc->driver->hangup_active(vc, generic_callback, vc);
> 		else
> 			return __ofono_error_not_implemented(msg);
> 
> 		return NULL;
> 	}
> 
> Should we do not_implemented here or did you intend the drivers to be allowed
> to not implement hangup_active nor hangup_all, and fall through to
> release_specific?

I think doing not_implemented here is a good idea.  However, you should
not take the ref of the message if you're returning not_implemented.
Something like this would be better:

if (call->status == CALL_STATUS_INCOMING) {
	if (vc->driver->hangup_all == NULL &&
			vc->driver->hangup_active == NULL)
		return __ofono_error_not_implemented(msg);

	vc->pending = dbus_message_ref(msg);

	if (vc->driver->hangup_all)
		....
	else
		....

	return NULL;
}

> 
>>
>>> @@ -286,12 +286,12 @@ static DBusMessage *voicecall_hangup(DBusConnection *conn,
>>>
>>> 	 num_calls = g_slist_length(vc->call_list);
>>>
>>> -	 if (num_calls == 1 && vc->driver->hangup &&
>>> +	 if (vc->driver->hangup_active && num_calls == 1 && vc->driver->hangup &&
>>
>> This should probably be a condition something like:
>>
>> if (num_calls == 1 && (vc->driver->hangup || vc->driver->hangup_active)
>> ...
>>
>>> 			 (call->status == CALL_STATUS_ACTIVE ||
>>> 				 call->status == CALL_STATUS_DIALING ||
>>> 				 call->status == CALL_STATUS_ALERTING)) {
>>> 		 vc->pending = dbus_message_ref(msg);
>>> -		 vc->driver->hangup(vc, generic_callback, vc);
>>> +		 vc->driver->hangup_active(vc, generic_callback, vc);
>>
>> And again prefer hangup_all over hangup_active to keep compatibility
>> with old drivers.
> 
> 
> Something like this then:
> if (num_calls == 1 && (vc->driver->hangup_all || vc->driver->hangup_active) &&
> 			(call->status == CALL_STATUS_ACTIVE ||
> 				call->status == CALL_STATUS_DIALING ||
> 				call->status == CALL_STATUS_ALERTING)) {
> 		vc->pending = dbus_message_ref(msg);
> 		 if (vc->driver->hangup_all)
> 			vc->driver->hangup_all(vc, generic_callback, vc);
> 		 else if (vc->driver->hangup_active)
> 			vc->driver->hangup_active(vc, generic_callback, vc);
> 		 else
> 			return __ofono_error_not_implemented(msg);
> 

Yep, but see the comment about dbus_message_ref above.

>> This reminds me that we should treat INCOMING calls in HangupAll
>> specially. It should not be handled here.
> 
> What did you have in mind?

I'm thinking of simply checking if there is an INCOMING call.  If so, it
is assumed to be a single call and using hangup_all / hangup_active is
sufficient.  This would also be more consistent with voicecall_hangup
implementation above.

> 
>> HangupAll should also skip waiting calls.
> 
> voicecalls_release_queue and voicecalls_release_next are used for
> multiparty_hangup as well, I assume you want the same behaviour for multi-party
> so that we can do these changes in voicecalls_release_queue, right?

Correct, however multiparty calls cannot be in the WAITING state.
Essentially we can just skip these by not queuing them on the release list.

> 
> Regards
> Sjur

Regards,
-Denis

  reply	other threads:[~2010-08-05 19:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 14:21 [RFC] STE-driver: Terminating voice call in state DIALING/ALERTING Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-08-05 16:24 ` Denis Kenzior
2010-08-05 19:04   ` Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-08-05 19:19     ` Denis Kenzior [this message]
2010-08-06 12:59       ` [RFCv2] " Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-08-06 19:01         ` Denis Kenzior
2010-08-06 21:30           ` Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=
2010-08-07  0:22             ` Denis Kenzior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C5B0EA5.80806@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox