BSC_Tests.ttcn is too tolerant in MGCP validation
The MGCP verification of BSC_Test.ttcn (particularly the as_Media altstep) is not very tight.
For example, we would currently not catch if one of the two MGCP connections (BTS or MSC side) is not established during AoIP.
Also, we would pass the tests using IPA/SCCPlite even when the BSC is issuing those extraneous MGCP commands for the MSC-side (which it isn't supposed to issue in SCCPlite).
- Status changed from New to In Progress
- % Done changed from 0 to 50
In order to catch cases where MGCP connections/interactions are missing I have integrated a counter that counts the occurrence of MDCX and CRCX interactions and compares them against an expected value. The machanism is now integrated and merged but unexpectedly causes problems with the LCLS teste. This needs to be investigated and fixed.
- % Done changed from 50 to 90
The reason why the LCLS tests were failing is because osmo-bsc starts to cross the connections before the BSSMAP ASSIGNMENT COMPLETE message has been generated. This means we are still in the f_establish_fully(). We have to expect another MDCX on the RAN side when LCLS is expected. This is now integrated and the tests should pass again now.
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10004 MSC_ConnectionHandler: more verbosity for f_check_mgcp_expectations()
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10005 MSC_ConnectionHandler: expect additional MDCX when call is LCLS
I think counting the MGCP interactions greatly improved the test coverage. We even managed to spot a regression that was not visible before (TC_ho_int). We could close this, however, I suggest to add a counting mechanism to the IPACC interactions as well. Those are also prone to develop silent regressions.
The TTCN3 test TC_lcls_connect_clear was passing for a short time and now fails again. But from what I can see the reason for this is not a miscounting of the MGW interactions. See also: #3413