CC: don't start guard timer on mid-call MNCC messages

The intent of the guard timer is to clear hung or stuck states
during call setup or teardown.  However, there are some MNCC
messages that will be exchanged between OsmoMSC (passing CC
messages to and from the MS) and the external MNCC agent during
the active call state, not related to setup or teardown: DTMF
start and stop, plus call hold and retrieve operations for call
waiting.  Unpatched OsmoMSC restarts the guard timer on every
received MNCC message, even those that pass through to CC without
affecting any state, and the result is breakage for users.

Consider the case of an IVR where you have to press some DTMF keys
before you can be transferred to a human operator.  You press the
needed keys, get the human operator, and start talking.  Then
3 minutes into your conversion (default guard timer duration)
your call unceremoniously disconnects without any warning.

Fix: look at the MNCC message type, and skip the call to start
the guard timer for known-benign MNCC messages.

Change-Id: Ibe2dd53f8e9e06d175b64df67d2a2e3e2d4155aa
This commit is contained in:
Mychaela N. Falconia 2023-06-26 05:30:29 +00:00 committed by falconia
parent e80f556cd4
commit 9b7de7480f
1 changed files with 21 additions and 1 deletions

View File

@ -2383,7 +2383,27 @@ static int mncc_tx_to_gsm_cc(struct gsm_network *net, const union mncc_msg *msg)
log_mncc_rx_tx(trans, "rx", msg);
gsm48_start_guard_timer(trans);
/*
* The step of gsm48_start_guard_timer() needs to be done for
* major state-impacting MNCC messages, but not for those
* that are a mere pass-through to CC messages to MS.
*/
switch (msg->msg_type) {
case MNCC_PROGRESS_REQ:
case MNCC_NOTIFY_REQ:
case MNCC_FACILITY_REQ:
case MNCC_START_DTMF_RSP:
case MNCC_START_DTMF_REJ:
case MNCC_STOP_DTMF_RSP:
case MNCC_HOLD_CNF:
case MNCC_HOLD_REJ:
case MNCC_RETRIEVE_CNF:
case MNCC_RETRIEVE_REJ:
case MNCC_USERINFO_REQ:
break;
default:
gsm48_start_guard_timer(trans);
}
trans->cc.mncc_initiated = true;
if (trans->msc_a)