The test cases used UPLINK RELEASE message as test for an unspported
message. This message is supported and does not trigger the expected RR
STATUS message. The fix uses the unsupported DTM ASSIGNMENT FAILURE
message.
To have the DTM ASSIGNMENT FAILE, it is added to
library/L3_Templates.ttcn.
Change-Id: I35877574cf4459332229e3b941918bc0a23b939f
The talker requests uplink. The UPLINK REQUEST is rejected by the MSC.
The uplink is marked free again.
Change-Id: Iba4dd21a69d49e6a8508b15b823ffccc7f0dafc9
The existing tests (talker fails, talker establishes, talker releases)
delay, so the MSC acknowledges the UPLINK REQUEST first. It is expected
that the events of the talker (failure, establishment, release) are
forwarded to the MSC after the acknowledgement.
New tests are added, so that the MSC acknowledges the UPLINK REQUEST
late. It is expected that the events of the talker are not forwarded
before the MSC acknowledges.
The BSC (under test) must queue the events of the talker before the MSC
has acknowledged the UPLINK REQUEST.
Change-Id: I28081e62287bdc17a3b477d9368f977aedce01c8
After sending UPLINK SEIZED COMMAND or UPLINK RELEASE COMMAND the timer
must be started, in order to collect data from the outcome of the test.
The test will fail sometimes, if this is not done.
Change-Id: Ic48e9c259b42ee6e030ea5d05b113ce2933e2247
The talker requests uplink. Instead of receiving link establishment from
the BTS, the BSC receives a link failure. The MSC expects to receive an
UPLINK RELEASE INDICATION, caused by radio link failure.
Change-Id: Ied56a6bdc0bfa541b1419e63e9e209ed20af804c
The MSC will block (seize) or unblock (release) the uplink on one BSC,
if a talker requests or releases uplink on a different BSC. An UPLINK
BUSY or UPLINK FREE message es expected to be sent to the BTS.
Change-Id: I7ebf03662e81f59d76ca8d8fa29f581043053564
There is no UPLINK BUSY message sent by BSC, if the talker
requests/establishes the uplink. Due to timing reason, the message is
sent by the BTS itself towards the MS.
Change-Id: I2e3b866eca174ae212ea986980d508e48e31fa57
It was recently decided it's a good practice to always specify the role
and sctp-role for all ASPs configured in the VTY, since it's an
important configuration providing feedback on the network setup
expectancies.
Change-Id: If48ca06f2cc3c0986daa5f6264d80138d468332a
Current osmo-bsc master does not support the MGW keepalive yet, so
f_vty_mgw_cfg_keepalive() fails. This leaves osmo-bsc in unclean
state and makes all LCLS testcases fail. The problem is that before
calling it we also call f_vty_mgw_enable() and f_vty_mgw_block(),
but not calling their counterparts.
Rearrange the testcase to call f_vty_mgw_cfg_keepalive() first,
so that we fail early before calling f_vty_mgw_{enable,block}().
Change-Id: I6a94c441fe80a92c237c3c4a5481f2dac3376e35
Fixes: bd59842b6 "bsc: Introduce test TC_mgwpool_keepalive"
Until recently, the asp-clnt-* ASPs, which have specific handling in osmo_sccp_simple_client_on_ss7_id(),
were being always forcedly set to sctp-role CLIENT by code in that
function.
This prevented user of that API from explicitly configuring the ASP as
"sctp-role server" through the VTY as the option would be overwritten silently.
Now, the sctp-role from config is followed if the ASP is
defined/configured through the VTY (not dynamically created at the time
osmo_sccp_simple_client_on_ss7_id() is called).
Since the default for a VTY-specified ASP is to be in "sctp-role
server", the config files need to be updated to properly configure the
ASP to be in "sctp-role client", which is the desired mode here.
Same applies for "role", where the default is SG but it is actually used
as "ASP" here.
Change-Id: I4eb5b5f6b4b24df079b4c74e2a2e2ebb8769b0bd
Fix the test for sccplite, where it fails at the third rate with:
Crit already present{ connid := omit, endpoint := omit, transid := omit }
For each rate that gets tested, a new expectation (Crit) gets set by
f_tc_assignment_csd() (f_establish_fully() -> f_create_mgcp_expect()).
If the expectation already exists at this point, it leads to the error
above. While the rate gets tested, the expectation gets removed in
MGCP_Emulation:main() (ops.create_cb.apply -> ExpectedCreateCallback()),
but only if the EP is not known.
So without this patch:
* T_14k4: passes, EP is not known, Crit gets removed
* T_9k6: passes, EP is known, Crit does not get removed
* T_4k8: error, because Crit already exists
Related: OS#4393
Change-Id: Ib8d27a670931105f45b994799c4757fffabdf97d
Fix the "Unexpected DLCX received" error in TC_assignment_csd with
sccplite. Without the patch, f_perform_clear() does not catch the DLCX
for sccplite.
Related: OS#4393
Change-Id: I9a3a4407510143af4bbc77a8cfe51a137945b716
Now that CSD is supported, rename the variable. It is true for both
voice calls and for CSD.
Related: OS#4393
Change-Id: Idfd9a102ad172d3aeaa4222a21357cdcd51680df
Verify that CSD ipaccess CRCX/MDCX has the CSD RTP payload type, and
that the RSL_IE_IPAC_RTP_CSD_FMT IE is set with
RSL_IPA_RTP_CSD_TRAU_BTS.
Related: OS#4393
Change-Id: Id0e0c5631d7a36635e1ef49cf5bf554f0336556b
Change the test so OsmoBSC always sends an BSSAP Assignment Failure by
setting the Data Indicator to an invalid value. Previously the test had
assumed that OsmoBSC would always send an Assignment Failure when
requesting CSD as it was not yet implemented.
The test only passed by chance on AoIP: OsmoBSC rejects the CSD
Assignment Request unless it has the Speech Codec List IE for AoIP.
Related: OS#4393
Change-Id: Ia4e8ab01dbadae5c9d7a964c0760dd3b016ab606
Don't fail the test if the BSSAP Handover Failure arrives after both
MGCP DLCX. In that case, the DLCX arrive at as_Media_mgw() in
MSC_ConnectionHandler. Set pars.fail_on_dlcx := false so it gets ignored
there and stays in the queue, until f_expect_dlcx_conns() in
f_tc_ho_in_fail_no_detect() takes care of them.
Fix for:
TC_ho_in_fail_no_detect(1979)@ba5f1f91fb11: setverdict(fail): none -> fail reason: "Unexpected DLCX received", new component reason: "Unexpected DLCX received"
Timeout of T_guard
BSC_Tests.ttcn:12410 BSC_Tests control part
BSC_Tests.ttcn:6990 TC_ho_in_fail_no_detect testcase
Change-Id: Ie0216504b6bdac38c2f7dcc23fc8e9a7e5acff57
Make the test pass with sccplite too.
Related: OS#5787
Fixes: 7a8594a8 ("bsc: TC_ho_in_fail_mgw_mdcx_timeout: new test")
Change-Id: If09c0ab5f668aefe262905bbd4f8c676f3b05fd3
Prepare to test CSD in BSC_Tests.ttcn. After sending a BSSAP assignment
request to the BSC with channel type data, the BSC will send a channel
activation via RSL to the BTS (which is emulated by the testsuite).
Without CSD support in the RSL template, the testsuite is unable to
decode the message, prints "Data remained at the end of the stream
after successful decoding" and the test fails.
Related: OS#4393
Change-Id: Ief2d95c7e9d71afb26fa74da755294226c8e158d
Fix that the test was torn down too early, before DLCX messages were
received from OsmoBSC. This caused a race condition that sometimes
failed the test with:
VirtMGW-MGCP-0(1996)@e5a096d6b4ff: Dynamic test case error: Sending data on the connection of port MGCP_CLIENT to 1999:MGCP failed. (Broken pipe)
Related: OS#5787
Fixes: 7a8594a8 ("bsc: TC_ho_in_fail_mgw_mdcx_timeout: new test")
Change-Id: If47fa3e0204ce841c79a67dd78a1c53d04e4a586
Prepare to use fail_on_dlcx in a new test case. Instead of dragging the
parameter through lots of function calls, just add it to pars.
Related: OS#5787
Change-Id: I6f0c4ce543724cc6f18bae9fc2b480f5818db8b7
The current BSC_Tests are using osmo-bts-omldummy to keep OML out of the test context.
Add a new test file and component for OML tests.
Change-Id: I0934ea26db359b0a6649c613f01de134a3a372ee
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
As stated in the comment near the t_def_TestHdlrPars definition,
valueof() shall not be used for getting a value of this template.
The f_gen_test_hdlr_pars() function should be used instead.
All LCLS testcases violated this, and started to fail since
recently after patch [1] has been merged:
"MSC_ConnectionHandler.ttcn:820 : Either imsi or imei must be set!"
BSC_Tests_LCLS.ttcn:743 BSC_Tests_LCLS control part
BSC_Tests_LCLS.ttcn:262 TC_lcls_gcr_only testcase
Use f_gen_test_hdlr_pars() as suggested.
Change-Id: I69ab8699b0be80b12e2df590d9170a743a00d035
Fixes: [1] b27653c6b6
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit makes sure TTCN3 tests pass valid l3 payloads to osmo-bsc,
so that they keep working once osmo-bsc starts rejecting invalid IEs it
parses.
Related: SYS#6280
Change-Id: I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit is another step towards passing proper l3 data to osmo-bsc
in TTCN3 tests.
Related: SYS#6280
Change-Id: I012dbdc673ff98a6647280ce3d0245abff86cfa4
Adjust the test to also check the special case ARFCN=0, which is at the
end of each sub list.
Related: OS#5717
Related: osmo-bsc Ic5e4f0531e08685460948b102367825588d839ba
Change-Id: Ia8f94d72651061427afc9e34f678544f89d0149b