> 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

For mpty calls this gets tricky.  I'd like some answers to these questions: - Can Emergency calls participate in mpty?

> Denis Kenzior <denkenz(a)gmail.com&gt; 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.

Hi Sjur, >>> 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. > > Initial testing on STE modem indicates that emergency call cannot > participate in multi call or be put on hold. What about a somewhat backdoor of putting call on hold on some modems: If a call is active, and you dial another call, the active call is automatically put on hold.  So if an emergency call is active and we dial another number, what happens?

> Yes, you're right using hangup_active will terminate all active calls > participating in a multi call. > So my proposal will not work as is. Maybe we need to know if > release_next was called for multi call? I have commited a fix for this that I think should work just fine.  Can you please check bab23b39767b664061ac2bcba747fe2b96561ca7 and let me know if it solves the issue?