Hi Sjur, > Hi Denis. > > We have done some testing with the STE modem for call termination, and this > is the result: > > TC |Call #1 | Call #2 | Call #3 | Command | Result > ---|-------------------------------------------------------------------- > 1 |ACTIVE | ACTIVE | .. | ATH | call 1, 2 terminated > 2 |ACTIVE | ACTIVE | .. | AT+CHUP | call 1, 2 terminated > 3 |ACTIVE | ACTIVE | HELD | ATH | call 1, 2 terminated > 4 |ACTIVE | ACTIVE | HELD | AT+CHUP | call 1, 2 terminated > 5 |ACTIVE | ACTIVE | HELD | AT+CHLD=0;H | call 1, 2 and 3 terminated > 6 |ACTIVE | ACTIVE | WAITING | ATH | call 1, 2 terminated > 7 |ACTIVE | ACTIVE | WAITING | AT+CHUP | call 1, 2 terminated > 8 |ACTIVE | HELD | WAITING | CHLD=0 | call 3 terminated, > 9 |ACTIVE | HELD | WAITING | ATH | call 1 terminated > 10 |ACTIVE | HELD | WAITING | AT+CHUP | call 1 terminated > 11 |HELD | HELD | ACTIVE | AT+CHLD=0 | call 1, 2 terminated > 12 |HELD | HELD | ACTIVE | AT+CHLD=0;H | call 1, 2 and 3 terminated > 13 |HELD | DIALING | .. | ATH | call 2 (MO) terminated > 14 |HELD | DIALING | .. | CHUP | call 2 (MO) terminated > 15 |HELD | DIALING | .. | AT+CHLD=12 | call 2 (MO) NOT terminated > 16 |HELD | WAITING | .. | AT+CHLD=0 | call 2 terminated > 17 |HELD | .. | .. | ATH | call 1 NOT terminated
Great table, makes it very easy to see what is going on. It looks like STE modems treat ATH and CHUP as only affecting dialing/alerting/active calls and incoming calls, not held calls or waiting calls. > > The standards are quite clear here, the WAITING call always takes > > precedence and thus only the WAITING call is affected. Can you check > > that STE modems do indeed get this wrong? If the modem is standards > > compliant, oFono does the right thing here. > > STE is standard compliant, only the WAITING call is terminated with > AT+CHLD=0. (TC 8) Excellent, I would have been surprised if STE behaved otherwise :) > > >> 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). > > > > Yes, so this is the case that we do need to take care of in the core. > > Most > > modems let us get away with sending release_specific up to this point. > > For the STE modem, calls in state DIALING and ALERTING will have to be > terminated with ATH or AT+CHUP, AT+CHLD=1x does not work. This means that > the current implementation, using release_specific (and thus AT+CHLD=1x) > will not work. Yep, so please critique my earlier suggestion of splitting up hangup into two methods: hangup_all and hangup_active. Modem drivers will need to provide one or the other or both. The core can then use the hangup_active (if available) in those cases where release_specific might not work. The condition for hangup_active will be that it does not affect held or waiting calls. For ST-E the hangup_active implementation will simply be +CHUP. For modems that do not have this available we will fall back to release_specific and assume that on those CHLD=1X or equivalent can affect dialing/alerting calls. hangup_all can also be used for cases where we loop release_specific over all active/dialing/alerting/held/incoming calls. For ST-E the hangup_all implementation might be +CHUP;CHLD=1n;...;+CHLD=1m where n, m, etc are ids of the HELD calls. We should not hangup waiting calls to be compliant with section 6.5.5.1 of 3GPP 22.030: "Entering END - Releases the subscriber from all calls (except a possible waiting call)." If this sounds OK then I will work on implementing the logic in the next few days. Regards, -Denis _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
