When CN RTP is missing, the X2 timer will fire after all other call
signalling looks successful. So far we establish an MT call, wait three
seconds and directly disconnect, long before X2 or X2427 can fire.
Make X2 shorter. (By means of f_vty_config() from ttcn, so that we don't
need to edit various osmo-msc.cfg in various repositories. The short
timer is always critical for the test to be accurate.)
Add proper function to detect premature disconnect. Otherwise we just
get a cryptic message like "Couldn't find MnccExpect for incoming call"
because of MNCC messaging after the unexpected release event.
Change-Id: I3ccf541360cc8440e664f0e29494b9ce7b6f8943
In f_tc_call_re_establishment_2(), after Assignment Complete, optionally
allow an MNCC_RTP_CREATE.
When Re-Establishing a call, the Assignment Complete usually affects
codec and RTP address, so an MNCC_RTP_CREATE should happen after the
Assignment Complete message.
Current osmo-msc master does not send this MNCC_RTP_CREATE. This is
unlikely to be correct (would be ok if no RTP port changes), likely
omitted due to a bug.
An upcoming patch adds the MNCC_RTP_CREATE in Call Re-Establishment to
osmo-msc.
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: I06d19947ba2e9b6696269db0e4f3d47d4b98bde6
When running ttcn3-bts-test natively (without Docker), the osmux
related testcases TC_speech_osmux_tch[fh] fail because both osmo-bts
and the testsuite are configured to bind() at '127.0.0.1:1984'.
Change-Id: I768933c83ae9dd2cd65eed955b2f823b6421cc4c
The problem was fixed in osmo-bsc.git quite some time ago:
commit 315af2f9ea1e8b9bf6e58caebd9dd7829edecfed
Author: Alexander Couzens <lynxis@fe80.eu>
Date: Mon Dec 19 21:21:32 2022 +0100
bts: ipa/osmo-bts/sysmobts: MO: add support for the second NSVC
Change-Id: I7f05c5cb840ac29e4919523a3d7eabd97974b583
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
Increase timeout for expecting an SCCP RLSD from osmo-hnbgw.
Affects tests
HNBGW_Tests.TC_ranap_cs_mo_disconnect
HNBGW_Tests.TC_ranap_ps_mo_disconnect
Rationale:
For the case
RUA --id-Disconnect--> HNBGW ----release-SCCP---- CN
the tests expect behavior not exactly specified.
3GPP TS 48.006 9.2 Connection release:
The MSC sends a SCCP released message. This message shall not contain
any user data field.
So what we should expect is this:
HNBGW MSC
RUA --id-Disconnect-------> | ---Data-Form-1(!)---> | Iu-ReleaseComplete
| <--Released---------- | (no data)
Instead, we expect the HNBGW to immediately send a RLSD to the MSC:
HNBGW MSC
RUA --id-Disconnect-------> | ---Released---------> | Iu-ReleaseComplete
osmo-hnbgw is being fixed in that respect: it will soon give time for
the CN to send an SCCP RLSD, and only if that times out will osmo-hnbgw
send an SCCP RLSD to the CN.
So HNBGW_Tests.ttcn should still ensure that osmo-hnbgw will eventually
send an SCCP RLSD if the CN fails to do so, but it should allow more
time to accomodate the release timeout.
Related: osmo-hnbgw I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
Related: SYS#6297
Change-Id: Ibf6eaeb1b82d43e4f208f64a71f2f6e889883a11
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
This happens if GTv2C failed prior:
"""
11:30:17.577738 15 PGW_Tests.ttcn:645 setverdict(fail): none -> fail reason: "Unexpected GTPv2 while waiting for CreateSessionResp", new component reason: "Une
xpected GTPv2 while waiting for CreateSessionResp"
11:30:17.578004 15 PGW_Tests.ttcn:756 Dynamic test case error: Initializing a TTCN_Buffer with an unbound octetstring value.
"""
Change-Id: I9731b755ddc7bb3ebd56bdec550961cc36f2e2c6
The function f_TC_amr_x_x_rtp_conversion() is called with RTP payload
octetstrings in the parameter list. Lets define constants for those
octetstrings so that it is better visible which RTP payload is which.
Change-Id: I7efc22e2f8a941e36200dda7841089e6c97185c6
The MGW now supports explicit HR GSM RTP format announcement via
SDP/fmtp. Lets add a testcase for this.
Depends. osmo-mgw.git Idde8da27fd335dc03b8fbd9e0fedc1491b77e9e4
Change-Id: If562955e7ae73b15dc3c4d742404741e20e31827
Related: OS#5688
Change-Id: I14421f780c4ef9e4c7e91182154070617852e957
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
osmo-hnbgw will deprecate the 'sccp cr max-payload-len' config option.
To still trigger the 130 byte limit that is now enforced in
libosmo-sigtran, enlarge the NAS PDU.
So far the limit set via VTY was 0 bytes, which will no longer happen in
osmo-hnbgw after I18dece84b33bbefce8617fbb0b2d79a7e5adb263.
Related: OS#5906 SYS#5968
Change-Id: I174b2ce06a31daa5a129c8a39099fe8962092df8
Currently an unexpected PDU will trigger a DTE (no matching alt).
Let's add an additional wildcard alt and terminate grecefully.
Change-Id: I6dbc646d5f036f454f197137373796f40c4c9e74
Related: SYS#5602, SYS#6333
The TC_nacc_outbound_pkt_cell_chg_notif_dup is currently failing
because in [1] we changed the default hard-coded MCC/MNC values in
ts_BssgpCellIdDstAddr_default, however these it's still using
hardcoded MCC=023/MNC=43. I overlooked this in [2].
Let's split up the f_handle_nacc_rac_ci_query() into four functions:
* f_ctrl_rx_nacc_rac_ci_req() / f_ctrl_tx_nacc_rac_ci_rsp(),
* f_pcuif_rx_nacc_rac_ci_req() / f_pcuif_tx_nacc_rac_ci_rsp(),
and use them in TC_nacc_outbound_pkt_cell_chg_notif_dup. Also
employ them in TC_nacc_outbound_pkt_cell_chg_notif_twice.
Change-Id: I3e84f55eedd278fb239600d6a0465bd34fd8cd0b
Related: [1] 03f74d4132
Fixes: [2] 7295661af5
Related: OS#5901
This patch fixes TC_nacc_outbound_si_resolve_timeout, which is still
using old hard-coded MCC/MNC values. The altstep does the same, but
relies on the updated values from ts_BssgpCellIdDstAddr_default.
Change-Id: I9f6dbe97e9a494a4e8fdb441a70999d3040f6cfd
Related: OS#5901
When setting up an RTP flow the fmtp string is checked using isvalue(),
however this does not guard against empty fmtp strings. Rejecting empty
strings is especially useful in situations where the caller wants to
signal using "" that no fmtp string is present.
Change-Id: I2641a52a3b271681f4f2e424c34be12e125092d6
Related: OS#5688
There is no such country/operator with MCC=023/MNC=43. Wireshark
complains about that when looking at the BSSGP messahes:
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
This may look confusing, let's better use some real country/operator:
Mobile Country Code (MCC): Central African Rep. (623)
Mobile Network Code (MNC): Celca (Socatel) (03)
Change-Id: Idc22128657d10893aa5c6d8ec80538a764de5c42
Related: OS#5901
The enc_* functions usually return an octetstring. However, both
f_enc_BcdMccMnc[_int]() return a sub-type of hexstring (BcdMccMnc),
so let's rename them to avoid confusion.
A follow-up patch adds the actual encoding function for BcdMccMnc.
Change-Id: I0332fe7396310da49910e89571f7181fb1604182
This is a partial revert of e9858efb90.
I was confused by weird MCC/MNC values in the Destination RAI generated
by the NACC testcases from the PCU_Tests.ttcn. As I figured out, these
values are not from the INFO.ind, but some hard-coded literals:
* SRC RAI: MCC=262/MNC=42/LAC=13135/RAC=0 (from ts_PCUIF_INFO_default);
* DST RAI: MCC=023/MNC=43/LAC=00423/RAC=2 (resolved by test itself);
so actually they're not incorrect: they're sent by the testsuite itself
in response to the Neighbor Address Resolution Request, and then
expected to be received in the Destination RAI from the PCU.
Another important point is that TITAN produces different results when:
a) converting BcdMccMnc to bytes using the hex2oct() function,
b) converting BcdMccMnc to bytes using the RAW encoder.
The key difference is that TITAN does swap nibbles in each byte when
using the RAW encoder, but does not when using the hex2oct() function.
Use the proper hexorder (low-to-high) in f_enc_BcdMccMnc().
Add a selftest to make sure we're encoding the input properly.
This change makes the NACC testcases pass again.
Change-Id: I6f497b97c4f1e270803e01530be8355beea740bb
Related: SYS#5602
Fixes: OS#5901
This config is out of sync with the one in docker-playground.git.
The 'neighbor resolution' param makes osmo-pcu use the CTRL interface.
Change-Id: I8d59096644afd5a5278bc7bb1335670edad72576
Related: OS#5901
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
In [1] I copied the hexstring concatenation statement for the 3-digit
MNC from the original function f_enc_BcdMccMnc(), which was renamed
to f_enc_BcdMccMnc_int(). Unfortunately, this statement (originally
introduced in commit [2]) is incorrect.
In our implementation a pair of MCC and MNC is encoded as follows:
| MCC digit 1 | MCC digit 2 | octet 1
| MNC digit 3 | MCC digit 3 | octet 2
| MNC digit 1 | MNC digit 2 | octet 3
Additionally, in the case of a 2-digit MNC, the original variant
of f_enc_BcdMccMnc() (before [1]) would swap MCC and MCC in the
2nd octet, generating even more unpredictable results.
According to 3GPP TS 24.008, Figure 10.5.13, the correct coding is:
| MCC digit 2 | MCC digit 1 | octet 1
| MNC digit 3 | MCC digit 3 | octet 2
| MNC digit 2 | MNC digit 1 | octet 3
So far the only user of this API is the PCU_Tests module. Looking
at the PCAPs of testcases invoking this function, Wireshark indeed
shows weird MCC/MNC values (expected 262/42):
Routing area identification: 23-43-423-2
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
Location Area Code (LAC): 0x01a7 (423)
Routing Area Code (RAC): 0x02 (2)
Change-Id: Ifa3083fdd6307b56baa1ef3ac85a3e7a2efab728
Related: [1] 7a92d5fbc0
Fixes: [2] 0637ba0728
Neels Hofmeyr
Vadim Yanitskiy
Oliver Smith
Pau Espin
Philipp Maier
Alexander Couzens