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
These two test cases verify that
* libosmo-sigtran doesn't include a routing context IE even in ASP
role when using a ASP with a single routing context 0 configured
* osmo-stp can route between a single SG-role ASP with routing context
to two ASP-role ASPs which both have routing context 0 (i.e. no
routing context IE in use)
The tests do not pass with current libosmo-sigtran until OS#6003 is
fixed, presumably by Change-Id I5ce89b393a3b950ab7fd1eace9038718c9efcc51
Change-Id: I81052ece7d1cc8b43da6155356ed1c4d9620acdc
Related: OS#6003
In some cases, there's some time between accepting the SCTP connection
and the execution of f_M3UA_CLNT_asp_up(). This may cause the
client sending re-transmitted ASP-UP messages. Let's simply flush
and ignore those, rather than failing the test case.
Change-Id: Iea39e9543535977a3004b150e222ce8c7f4d821a
The 3rd-party M3UA_Emulation supports operation both with and without
a routing context. Let's make sure the layers we build on top don't
lose that capability by forcing routing context usage.
Change-Id: Iff849953d923770c93029a6a5c5b86daa8c38f1e
The params are set in GGSN_Tests.cfg and not in GGSN_Tests.default,
because those lower values are not really good default ones as per spec.
For instance when running against open5gs-smfd, these values should be
left to the default in code of 5 and 3 seconds, because open5gs-smfd
doesn't support changing the values through cfg file yet.
Related: OS#5485
Change-Id: I3798fba89c2c357afeaa83a73759442c6c433cea
The old test was not really correct, since it is fine for the BTS to ACK
the RSL CONNECT despite later on failing to connect the RSL link.
RSL_CONNECT is really just setting the attributes (it could even be
replaced by SETATTR in the future), and connect happens later on.
This can still be found out by the BSC because the BBTRANSC will never
transition to a Enabled state until the RSL link becomes up.
This patch repurposes the existent test to do some more meaningful check
in a case the RSL CONNECT can be answered with a NACK. This scenario was
actually failing to be properly checked in osmo-bts until recently, so
it is expected that it will fail (and even crash) older versions of
osmo-bts.
Depends: osmo-bts.git Change-Id If27639ae1727fc5232e1a964a1b29f50c8805d80
Related: OS#5964
Change-Id: I10df611f0086d34a5482f7c8a79703938313ab3d
Some components directly report being activated. Let's allow it.
This fixes TC_initial_state_reports.
Change-Id: I054dc74f60edee027923f03f8e73e56b1dc11a83
This way we stop vc_IPA_OML before stopping the main component.
If we don't do this, the vc_IPA_OML is potentially receiving tons of OML
messages during BTS bringup which it tries to forward to the main
component. If the main component has stopped at that point, port
IPA_OML_PORT is no longer active and hence vc_IPA_OML fails with a
dynamic test error.
Change-Id: I761ae94aa698a74bb30b8a6b1860358545f222b5
This will hopefully help fix sporadic errors while tearing down the test
after successful run:
mtc BTS_Tests_OML.ttcn:625 Removing unterminated connection between port IPA_OSMO_PCU and TC_ts_opstart-OML-IPA(15):IPA_OSMO_PCU_PORT.
IPA_Emulation.ttcnpp:774 setverdict(error): none -> error
Related: OS#5965
Change-Id: I53c065016e88a5b253eff496560fa6e371fe491b
End the guessing when seeing "timeout of T_guard": set a precise failure
verdict when an expected RANAP/SCCP ("BSSAP") message did not arrive as
expected.
Change-Id: I51c60ed8fcef83c98e6c62c9f62a8c3c665de860
End the guessing when seeing "timeout of T_guard": set a precise failure
verdict when an expected PFCP message did not arrive as expected.
Change-Id: I2117475b695d486b1204d61e5bb21120a6187354
End the guessing when seeing "timeout of T_guard": set a precise failure
verdict when an expected RUA message did not arrive as expected.
Change-Id: I29e6b7659ba53efee9f676197b502f79780ead7e
This parameter enables running additional TC_pcu_* tests.
Both trxcon and virtphy do support GPRS (l1gprs) now.
Change-Id: I68351bf45fa3470a3a25eae2110056abae39af47
Change [1] fixes support of dynamic timeslots in osmo-bts-virtual,
so we don't need to change the pchan configuration anymore.
Change-Id: I98397ac0fc17ece8f0e41b1ef1c158b47c9de026
Related: [1] osmo-bts.git I5db5b7dd6a8e84cf9a0d84f04a650c2ed8a4e368
When calling f_pcu_to_l1(), the L1CTL port still contains many BCCH
related L1CTL DATA.ind messages in the queue. It's not a really a
problem since they all get discarded, but still they're producing
lots of useless TTCN_MATCHING log messages.
Change-Id: I57b745bcfc48dc621359658cd43d2ee622fde49b
The testcase expectations are wrong, because when matching the
PCU_IF_MSG_NEIGH_ADDR_REQ on the PCU port, TITAN's RAW codec reasonably
chooses the 'neigh_addr_req' field in the PCUIF_ContainerMsgUnion, not
the 'other' field as expected. The 'other' field would be choosen if
the 'msg_type' is not PCU_IF_MSG_NEIGH_ADDR_{REQ,CNF}.
A quick and dirty fix would be changing the PCU_IF_MSG_NEIGH_ADDR_REQ
to something else, e.g. PCU_IF_MSG_CONTAINER. This would make both
encoder and decoder agree on the union field to be used and would work
in theory (because for some reason we reuse PCUIF_MsgType as the
container payload type, and osmo-bts does not really care about the
payload), but I don't really like this approach.
I believe we should be sending realistic payloads instead.
Change-Id: Id4a6ecf5b271a16645a42c8bea22f47869f7c81f
Closes: OS#5963
Add Message types for Radio Resource management messages using
the RR short protocol discriminator from Table 10.4.2 3GPP TS 44.018
Related: OS#5783
Change-Id: Id3b59638a3cf75c7105b1992094a4cc20855161d
The old GPRS related messages are no longer valid. Use the new message
definitions supported by both trxcon and virtphy since recently.
Comment out lines referencing the old definitions in LAPDm_RAW_PT.ttcn.
This module contains an implementation of the RLC/MAC abstraction
layer, which is currently not used anywhere.
Change-Id: Ib8f4459480bbe12584a6fa71882f745f03c5055d
Related: osmocom-bb.git I9567d64f9d00262e36147e8d7e541e5e246bda5f
Related: OS#5500
Currently we have two variants of the L1CTL PDU:
* L1ctlUlMessage: L23 -> L1 requests (*_REQ),
* L1ctlDlMessage: L1 -> L23 responses (*_IND, *_CONF).
The L1CTL_PT port is defined in a way that one can:
* Tx L1ctl{Ul,Dl}Message PDUs,
* Rx L1ctlDlMessage PDUs.
This means that the testsuite can act as the L23 talking to the L1
(e.g. trxcon or virtphy), but not vice-versa. Adding an additional
Rx `UD_send_data -> L1ctlUlMessage` mapping is not an option,
because such a mapping would be ambiguous and would cause errors.
By merging the two L1CTL PDU variants into the one, we can achieve
the testsuite acting as the L1. This will be useful for testing
the L23 applications in osmocom-bb.git, like the modem app.
Take a chance to reorder fields to match the order in L1ctlMsgType.
Change-Id: I1313068c5f02b65d3dbb05a1341a9d7286225f0c
Related: OS#5500
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
Oliver Smith
Harald Welte
Pau Espin
Neels Hofmeyr
Vadim Yanitskiy
Max
Philipp Maier