FW: FW: [RFC 3/3] STE-plugin: Adding STE plugin
by Sjur Brændeland
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.
BR/Sjur
10 years, 4 months
- 1
- 0