CC: intentionally release T308 on BSSMAP Clear Request from BSC
So far we hit a running T308 during CC release when caused by a BSSMAP Clear
Request, and we loudly log that as error.
However, now I understand that T308 is a direct cause of the dispatch of a REL
IND towards MNCC, which is used to indicate teardown to MNCC. So during
_gsm48_cc_trans_free(), we first clear all timers, then invoke
mncc_release_ind() which starts another timer (useful for graceful CC Release,
but in this code path the intention is immediate release). Simply immediately
cancel the timer again and release the conn.
A separate question is whether a BSSMAP Clear Request should be less aggressive
in releasing the connections; i.e. instead of calling trans_free() all around,
to rather ask each transaction to "please stop soon", somehow.
Related: OS#3062
Change-Id: I231fdb574a086a206321148474cbdc7ca9cf39f0
diff --git a/tests/msc_vlr/msc_vlr_test_call.err b/tests/msc_vlr/msc_vlr_test_call.err
index 6142464..1b8002b 100644
--- a/tests/msc_vlr/msc_vlr_test_call.err
+++ b/tests/msc_vlr/msc_vlr_test_call.err
@@ -1085,8 +1085,8 @@
DMNCC transmit message MNCC_REL_CNF
DCC Sending 'MNCC_REL_CNF' to MNCC.
MSC --> MNCC: callref 0x423: MNCC_REL_CNF
+DCC stopping pending timer T308
DCC (ti 00 sub MSISDN:42342) new state RELEASE_REQ -> NULL
-DCC MSISDN:42342 Timer 0x308 is still running while discarding transaction -- this is a bug: we were still expecting a response but are freeing the transaction anyway
DREF VLR subscr MSISDN:42342 usage decreases to: 2
DREF MSISDN:42342: MSC conn use - trans_cc == 1 (0x4)
- Iu Release --RAN_UTRAN_IU--> MS