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 Denis Kenzior wrote: >>> 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). > > The standards specify that CHLD=1X can only terminate an ACTIVE call. > Most modems implement it this way. There are vendor extensions that > provide this functionality (e.g. CHLD=7X on TI.) By default oFono > assumes that release_specific will simply fail if a user attempts to > use it on an e.g. HELD call with no modem support. For the STE modem, AT+CHLD=1x terminates calls in state ACTIVE and HELD. >> >> 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). > > Ok, lets get the terminology clear here. In this case the incoming > call is not ALERTING, it is WAITING. WAITING calls are always > rejected by using CHLD=0. ALERTING calls are always outgoing calls > that transitioned from DIALING to alerting the user. > >> >> 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 > > 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) >> >> 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. >>> 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 >>> same behavior? >> >> 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 either... > > Can you check the behavior of ATH vs CHUP on STE modems? We need to > send the right one here or both HELD and ACTIVE/DIALING/ALERTING will > be terminated. > If using CHUP and ATH doesn't work out we'll have to come up with > another solution. For the STE modem, ATH will only terminate the active call, not the held call. (TC 9). For more information about ATH and AT+CHUP, please see the table above. BTW: Sorry if you get this mail twice, something went wrong when posting this last time so I'm had to re-send this. BR/Sjur _______________________________________________ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
