Bug #3292
closed
BSC_Tests.ttcn is too tolerant in MGCP validation
Added by laforge almost 6 years ago.
Updated over 5 years ago.
Description
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).
- Tags changed from SCCPlite to SCCPlite, TTCN3
- Project changed from OpenBSC to OsmoBSC
- Assignee changed from laforge to dexter
- 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.
Checked why TC_ho_int is failing. I expected that something is wrong with the new test expectations, but it seems to be a real bug this time, see: #3396
- % 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
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF
