Denis Kenzior wrote:
>> All of this logic needs to go away. The core already handles all of
>> this, including selection of ATH/CHLD, waiting/held. Please review
>> src/voicecall.c. If the core logic is not sufficient or does not
>> properly handle a certain case, then lets see if we can fix the
>> core first. Drivers should not concern themselves with this stuff.
> OK, we can remove the state logic, but STE modem cannot terminate
> calls in state DIALING and ALERTING with CHLD=1X. We need to use ATH
> (or AT+CHUP) instead.
oFono already takes care of this for single calls (see src/voicecall.c
voicecall_hangup.) So this is only an issue in the case of three way
calls, is this what you're referring to here?
Kind of. This is very good, it
takes care of the situation with emergency call
which cannot be terminated with CHLD commands.
But I think there are more issues. If I am not mistaken STE-modems have
the following behavior:
CHLD=1X can only terminate call in state ACTIVE or HELD. (I think
this is as STE interprets the standards).
a) If you are in a active call and receives a new incoming call (ALERTING)
and want to reject the new ALERTING call, then STE modem cannot
terminate this call with CHLD=1X. It has to be terminated with CHLD=0
(cause=BUSY) or ATH (possible CHUP).
b) Or you may have the following situation. One call on HOLD,
another ACTIVE call, and then you receive a new incoming call ALERTING.
If you try to terminate the new incoming (ALERTING) call with CHLD=0,
I think you as a side effect will terminate the call on hold as well.
If I am not mistaken ATH (possible CHUP) would be the correct in this
situation for STE modems
c) If you have an call on hold and initiate a new call, but want to
terminate the newly initiated call (DIALING), then this call cannot be
terminated with CHLD=1X, but you would have to use ATH (or possible CHUP).
> For now I think we will remove the state logic from
> ste_release_specific as you suggest. Terminating calls in state
> DIALING and ALERTING must then be handled by the Core part. The
> simplest would probably be to use hangup in this case, but I suspect
> hangup work differently for different modems. So if you cannot use
> hangup as the general approach, maybe it could be
> implemented by adding callback functions release_dialing and
> release_alerting in struct ofono_voicecall_driver. The STE driver
> could send ATH from release_dialing and release_alerting, other
> drivers could leave them empty and this could default to use
> release_specific instead?
What I referred to here was the solution to the
situations described above
What I have been considering to take care of this case is to add
end_all and end_all_active callbacks. According to 27.007/22.030 ATH
should end all calls (active + held) except waiting calls, while
+CHUP should only end the currently active call. At least on one TI
modem I tried this works as expected. Do your modems implement the
No, I don't think so. I think ATH will only terminate one call.
In order to terminate all calls you would probably need to do something
like: AT+CHLD=0;H But I'm not sure this works in all possible scenarios
If so then we can always use end_all_active for
>> With this in mind, you might not need to track any state in this
>> driver at all. See drivers/calypsomodem/voicecall.c for details.
>> TI's CPI notifications are almost exactly the same as the STE ECAV.
> The STE ECAV update is giving delta updates on the state information,
> right now I don't see how we can get the ofono_voicall_notify right
> without keeping some state information in ecav_notify.
Yes you're right, I was assuming ECAV gives you more information on
whether the call was released locally or remotely.
Finally I'm not in office so I have taken this from top of my head so
I might have got something wrong here.