Bug #3639
closed
TC_assignment_sign, TC_ciph_mode_a5_0, TC_ciph_mode_a5_1, TC_ciph_mode_a5_3 do not pass in the sccp-lite testsuite
Added by dexter over 5 years ago.
Updated over 5 years ago.
Description
There is a regression with the following tests:
TC_assignment_sign
TC_ciph_mode_a5_0
TC_ciph_mode_a5_1
TC_ciph_mode_a5_3
This needs to be fixed.
- Status changed from New to In Progress
Please note it appears to only be a regression in the SCCPlite case?
- Subject changed from TC_assignment_sign, TC_ciph_mode_a5_0, TC_ciph_mode_a5_1, TC_ciph_mode_a5_3 do not pass to TC_assignment_sign, TC_ciph_mode_a5_0, TC_ciph_mode_a5_1, TC_ciph_mode_a5_3 do not pass in the sccp-lite testsuite
The problem is now fixed, however one of the main problem was that MSC_ConnectionHandler does not really know if AoIP or sccplite style messages should be used. During f_establish_fully() this is decided by looking at the CIC parameter in the assignment command. If it present sccplite is assumed. However, this is not a very good pivot point to check since for signalling channels no CIC is present anyway. I think we need an explicit setting that determines if AoIP style messages or sccpplite messages are expected.
The following patch adds an aoip flag and makes sure that it is set properly. I made sure to test this with the testsuite for Aoip and sccplite.
See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11289 MSC_ConnectionHandler: Use explicit AoIP flag
- % Done changed from 0 to 90
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
The patches are merged and the tests are passing. I think we can close this task.
Also available in: Atom
PDF
