MSC_Tests: fix TC_mo_crcx_ran_reject
The testcase intentionally responds to the RAN sided CRCX
with a garbeled message to cause the MGCP handlin inside
the MSC to fail. The MSC is then expected not to perform
further MGCP operations since it did not get a proper
response to the first CRCX, so the specific endpoint name
is not known, eventually preventing from doing an MDCX.
However, the testcase responds to incoming DLCX commands,
instead setting the verdict to fail.
Also the altstep that dispatches the message after the
errornous MGCP response unconditionally catches all BSSAP
messages before entering the sub-altstep
as_clear_cmd_compl_disc() that handles the clearing of
the connection. Eventually the clear command is never
received in this sub-altstep.
- Make sure the verdict is set to fail when an MGCP
message is received after the errornous response to
the CRCX.
- Remove the unconditional BSSAP.receive in order to
be able to dispatch the clear command properly
- Update the expected-results.log file
Change-Id: I806491741d310e4410f6cb4ce0309235e9bf4300
Related: OS#2882
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn
index b5108c7..bb28c74 100644
--- a/msc/MSC_Tests.ttcn
+++ b/msc/MSC_Tests.ttcn
@@ -1267,17 +1267,14 @@
BSSAP.send(ts_PDU_DTAP_MO(ts_ML3_MO_CC_REL_COMPL(cpars.transaction_id)));
repeat;
}
- [] BSSAP.receive {
- repeat;
- }
[] MNCC.receive { repeat; }
[] GSUP.receive { repeat; }
- [] MGCP.receive(tr_DLCX(?)) -> value mgcp_cmd {
- MGCP.send(ts_DLCX_ACK2(mgcp_cmd.line.trans_id));
- f_create_mgcp_delete_ep(cpars.mgcp_ep);
- repeat;
- }
- [] MGCP.receive { repeat; }
+ /* Note: As we did not respond properly to the CRCX from the MSC we
+ * expect the MSC to omit any further MGCP operation (At least in the
+ * the current implementation, there is no recovery mechanism implemented
+ * and a DLCX can not be performed as the MSC does not know a specific
+ * endpoint yet. */
+ [] MGCP.receive { setverdict(fail, "Unexpected MGCP message"); self.stop; }
[] as_clear_cmd_compl_disc();
}
}