ttcn3
/
osmo-ttcn3-hacks
mirror of https://gerrit.osmocom.org/osmo-ttcn3-hacks
10
0
Fork 1
Code Issues Releases Wiki Activity

bsc: Fix regression in TC_assignment_emerg_setup_deny_bts 

A recent commit introduced a regression which made
TC_assignment_emerg_setup_deny_bts fail.

The problematic commit (see hash below) set "pars.ra :=
f_rnd_ra_emerg()" in the helper function, which made the BSC early
reject the CHAN RQD with ImmAssRej in the case the BTS policy forbids
emergency calls.
In that scenario, rejection can be done early because there's no need to
wait to find out which MSC it is aimed at.
This scenario, however, is already being validated by test TC_chan_rqd_emerg_deny.

The scenario TC_assignment_emerg_setup_deny_bts was testing is actually
one where CHAN RQD doesn't contain reason="emergency call", which means
BTS doesn't early reject it, but only knows about it being an emergency
call when a CC Emergency Setup is sent to it, time at which it releases
the call.

Hence, this commit sets back pars.ra = f_rnd_ra_emerg() only on the ..._deny_msc
testcase, since it's the only test really needing it.

Fixes: 14076d3b72
Related: OS#5849
Change-Id: I8d342e5938f6293ae45ee399796417651768af5d
This commit is contained in:
Pau Espin 2023-01-17 12:06:03 +01:00
parent bc612766ea
commit 6b869f49d1
1 changed files with 10 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
bsc/BSC_Tests.ttcn
View File

@ -9249,10 +9249,6 @@ private function f_TC_assignment_emerg_setup_deny(charstring id) runs on MSC_Con
var PDU_BSSAP emerg_setup_data_ind_bssap;
timer T := 3.0;
/* Make sure the CHAN RQD indicates an emergency call (0b101xxxxx). The difference is that osmo-bsc directly
* assigns a TCH lchan and establishing voice for the emergency call will use Mode Modify, not reassignment to
* another lchan. */
g_pars.ra := f_rnd_ra_emerg();
f_assignment_emerg_setup();
T.start;
@ -9316,12 +9312,19 @@ testcase TC_assignment_emerg_setup_deny_msc() runs on test_CT {
f_vty_allow_emerg_msc(false);
f_vty_allow_emerg_bts(true, 0);
/* Make sure the CHAN RQD indicates an emergency call (0b101xxxxx): */
pars.ra := f_rnd_ra_emerg();
vc_conn := f_start_handler(refers(f_TC_assignment_emerg_setup_deny), pars);
vc_conn.done;
f_shutdown_helper();
}
/* EMERGENCY CALL situation #3, allowed globally but forbidden by BTS */
/* EMERGENCY CALL situation #3, allowed globally but forbidden by BTS.
* The RACH req (and hence CHAN RQD) indicate other than emergency call.
* Hence BSC only learns about it being an emergency call later during call setup.
* If interested in the ra="emergency call" + deny bts policy case,
* see TC_chan_rqd_emerg_deny.
*/
testcase TC_assignment_emerg_setup_deny_bts() runs on test_CT {
var TestHdlrParams pars := f_gen_test_hdlr_pars();
var MSC_ConnHdlr vc_conn;
@ -9329,13 +9332,14 @@ testcase TC_assignment_emerg_setup_deny_bts() runs on test_CT {
/* Note: This simulates a spec violation by the MS, correct MS
* implementations would not try to establish an emergency call because
* the system information tells in advance that emergency calls are
* not forbidden */
* not allowed */
f_init(1, true);
f_sleep(1.0);
f_vty_allow_emerg_msc(true);
f_vty_allow_emerg_bts(false, 0);
/* Note: Here we implicitly leave default g_pars.ra which is different than "emergency call" */
vc_conn := f_start_handler(refers(f_TC_assignment_emerg_setup_deny), pars);
vc_conn.done;
f_shutdown_helper();