Hi Sjur,

Sjur Br?ndeland wrote:
> Denis Kenzior <denk...@gmail.com> wrote:
>>> I thought of one more issue with voice calls.
>>> I don't think it is safe to to terminate emergency calls using
>>> release_specific, AT+CHLD=1X. At least this don't work for STE
>>> modems. 
>>> 
>>> I suggest calls in state active should be terminated using
>>> hangup_all or hangup_active. What do you think?
>> 
>> So in the case of a single call, the emergency call will be
>> terminated using hangup_all / hangup_active anyway.  I have relaxed
>> the single call restriction for active calls when hangup_active is
>> provided by the 
>> driver.  Refer to c7b13ec2fe664b122216a312f2442c9ca26f5f43
> 
> Yes, it seems to be ok for voicecall_hangup, but in manager_hangup_all
> the active call is still terminated with release_specific in
> voiceall_release_next.
> This implies that if you have an emergency call and terminate it with
> manager_hangup_all AT+CHLD=1X still will be used, right?
> 
> I suggest we change voicecall_release_next like this:
> 
>       if (vc->driver->hangup_active != NULL &&
>                       (call->call->status == CALL_STATUS_ALERTING ||
>                               call->call->status == CALL_STATUS_DIALING ||
> +                             call->call->status == CALL_STATUS_ACTIVE ||
>                               call->call->status == CALL_STATUS_INCOMING))
>               vc->driver->hangup_active(vc, multirelease_callback, vc);
>       else
>               vc->driver->release_specific(vc, call->call->id,
>                                               multirelease_callback, vc);
> 
>> For mpty calls this gets tricky.  I'd like some answers to these
>> questions: 
>> 
>> - Can Emergency calls participate in mpty?
> 
> I have to verify this with some of my colleagues, but I am pretty sure
> emergency calls cannot be applied to the AT+CHLD command. i.e. they
> cannot be part of mpty.

If emergency calls cannot be part of mpty call, we can use either hangup_all or
hangup_active as Denis said. However, your suggested fix will break multiparty 
call
scenario since multiparty_hangup calls voicecall_release_next as well. Maybe we
should use call->type to indicate whether it's an emergy call. It looks to me 
that the
type flag in struct ofono_call hasn't been used yet. Correct me if I am wrong.

> 
> Regards
> Sjur
> _______________________________________________
> ofono mailing list
> ofono@ofono.org
> http://lists.ofono.org/listinfo/ofono



Regards,
Zhenhua
_______________________________________________
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono

Reply via email to