Since recently [1], osmo-bts does submit all PCUIF DATA.ind regardless
of the Uplink link quality (C/I ratio in case of osmo-bts-trx).
Change-Id: If801e9112c1207ccdc40f9e675c52fadccdd1411
Related: [1] osmo-bts.git I8f1856dd9061c1bfca8b15be30df7a51760231b0
We must be using a valid TDMA Fn when scheduling UL BLOCK.req,
so wait for a DL BLOCK.ind, take the current Fn from there and
calculate a proper TDMA Fn for the next UL block.
Change-Id: If0fb615a4136a76a939588af0131ddcfb7acd877
Related: OS#5954
This altstep eliminates the need to wrap the actual PCUIF message
template into another (port specific) template t_SD_PCUIF.
Change-Id: Iabefddd54a4a2e2183feea04fdb8526e74efc7ac
Currently the TC_acch_overpower_* testcases are all passing without
any sporadic failures. However, most of them start failing due to
a DTE (some RSLEM related race condition) if I apply a patch [1] to
trxcon removing its internal TDMA clock module.
I don't know why this happens, but releasing the DCCH after executing
all testcase steps in f_TC_acch_overpower() makes that DTE go away.
Change-Id: I658e78ad8d4dc86403d22b5380ddd9a140f8c71c
Related: [1] osmocom-bb.git Ic8a5b6277c6b16392026e0557376257d71c9d230
Related: OS#5500
All testcases based on f_TC_speech_rtp() consist of two parts:
* In the first part we expect to receive a Downlink frame at the MS,
and, once received, we echo the received frame back to the BTS.
* In the second part we expect to receive an Uplink frame, the one
that was echoed back during the first part.
Let's keep echoing Downlink TCH frames while executing the second
part in order to reduce possibility of race conditions and keep
filling-up the Tx queue in the virtual MS (trxcon). Also keep
sending dummy Measurement Reports on SACCH.
Change-Id: Ifb69669b75df5b390d7056cefaf0ef1df69d9bd4
Related: OS#1572, OS#4396
The testcase TC_one_crcx_loopback_rtp_implicit creates a loopback
connection using CRCX but without SDP. It selects AMR using LCO. The MGW
responds with an MDCX and acknowledges AMR with a payload type of 112,
The TTCN3 testcase then sends AMR RTP packets with payload type 111, those
are accepted and looped back but the payload type will be converted to 112
as negotiated in the CRCX response. However the TTCN3 test still expects
111 in the packets comming back from the MGW. This is obviously a wrong
expectation and the testcase did only pass because Osmo-MGW was behaving
incorrectly.
To fix this let's just use 112 as payload type as payload type in this
test. This is the recommended payload type number for AMR (3GPP TS 48.103,
Table 5.4.2.2.1) and used by the MGW by default in case the call agent does
not specify a different one in SDP.
Change-Id: Idc370e9dc2e4954374fc7d07f7b117788028635a
Related: OS#5461
The record PCUIF_pch_dt, coresponds to struct gsm_pcu_if_pch_dt in
pcuif_proto.h. It will be needed when we introduce support for the TLLI
based confirmation of IMMEDIATE ASSIGNMENT messages that are sent via
the PCH.
Related: OS#5927
Change-Id: Ia705d3a6fe7adb863acd29e968f8dc6b2066a497
Since recently [1], osmo-bts started to preen incoming FR and EFR RTP
frames for SID errors. In other words, if an incoming frame is a SID
frame, osmo-bts may modify some bits causing a mismatch on our side.
Use 'FF'O as padding pattern for TCH/FS to prevent pseudo-random frames
being treated as SID and modified by osmo-bts. Keep using '00'O for
other modes, because only TCH/FS specific SID frames must have specific
bit positions set to '0'B; for TCH/EFS and TCH/HS it's '1'B.
Change-Id: Ib42b783574caf5cbaf64b2eb5dd1d2b2a6637c2f
Related: [1] osmo-bts.git I89df2f12c49dd5378667cf149d19bde654f80134
Related: OS#6039
A record for the message type PCU_IF_MSG_DATA_CNF_DT exists with
PCUIF_data_cnf_dt, but there are no tr_ or ts_ templates yet.
Related: OS#5927
Change-Id: Iccde71e1dd6fbd421652c5892bc2c1f32a8535ff
The octet aligned to bandwith efficient conversion is currently only
tested in scenarios where only one codec is assigned on both sides.
However, there may be call agents that will assign bandwith efficient
and octet aligned on one side for compatibility reasons. If this is the
case, then OsmoMGW should always chose the format that requires no
conversion.
Related: OS#5461
Change-Id: I2b2d7ef7fb4fe31111aa8665c4d4295425502451
"according to a comment in f_gmm_attach() there's an encoder problem if it's omit. This sounds like the ts_GMM_ATTACH_REQ()
should be changed to define solSACapability as '0' insteads of omit. At that point none of the users of ts_GMM_ATTACH_REQ
will need to manually modify it anymore."
(quote: hwelte on Gerrit (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/31199/comments/17ed155d_cc58810a))
Related: OS#4221
Change-Id: I9eaa39274456e5cc0a1cf025bf956970efc4a51f
The individual timeouts in TC_BVC_bringup_conflicting add up to almost
15.0s (the Tguard timeout) which causes the test to sometimes fail.
Decrease the time waiting for all BVCs to be unblocked from 10s to 5s,
in reality this should be plenty time.
Change-Id: I620ce90f9e6b54cc94b4d36ac123f43d8d809f47
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
Even though we do not need it right now, let's add the message type
PCU_IF_MSG_E1_CCU_IND. This message type has been added to the PCUIF
protocol recently.
Related: OS#5927
Change-Id: Ib6482d88e924f285658b933f32be42a4f63bee71
It was decided that the preferred way to maintain our eclipse titan
forked repos is through gitea, not through gerrit. Hence, update the
remote to point to the gitea repo. The gerrit one will probably be
removed at some point.
Related: OS#6011
Change-Id: I69f8e207a28b8ea424d8fa4f23bdcaa3ba2e1345
The SAPI PCU_IF_SAPI_AGCH_DT has been renamed to PCU_IF_SAP_PCH_DT in
the recent pcuif_proto.h version since the IMMEDIATE ASSIGNMENT what it
is used for is sent on the PCH not on the AGCH.
The SAPI constant is currently not used in the TTCN3 testsuite, but it
will soon be used when we introduce support for the recent PCUIF which
will then use the direct TLLI (DT) method.
Related: OS#5927
Change-Id: Ifc09067bcb0f9f422ca429313fa09fea081dc316
Got this while pulling in the entire set of deps:
"""
remote: You have reached the limit of requests you can make to Eclipse GitLab.
This could be caused by too many open tabs, which query the GitLab server in
the background. Please close unused tabs, or put them to sleep so they don't
issue requests needlessly.
"""
Change-Id: I5866154a6af88875a446e092f0926cdc4a1a9fc4
The master branch in osmocom's gerrit repository has been rebased on top
of current upstream master, hence the commit hash changed. Update it.
Related: OS#6011
Change-Id: Ife9dba3fc98d287d71b2334453dd9ce71471ddcb
The template RtpFlowData is defined in the middle of the code, lets move
it up below the related record definition
Change-Id: If854f708e4da8b3a7b02d1ace2eb7caa3e2f2bfb
When creating a flow with fmtp parameters we must always add them in a
second step. Lets update t_RtpFlow, so that it supports fmtp as an
optional parameter.
Change-Id: I04b17c0d233c1db4b9ba1306a4e0555914519bf8
At the moment The RTP emulation and MGCP_Test only allow to specify one
codec and one set of RX/TX fixed payload octet strings to verify against.
This is quite limiting since it might be necessary to test against
different types and formats of payloads simultaneously in order to see
if osmo-mgw converts or forwards them correctly.
Let's extend this to support multiple codecs on MGCP/SDP level plus
support for multiple RTP payloads on RTP emulation level.
Related: OS#5461
Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
Use this fix in our tests:
17a894fc66
This allows osmo-hnbgw to start out with SCCP local reference == 0
without that causing test failure.
'Related' patch below happens to have that effect, and it was *really*
hard to find out why th the tests failed. It seemed like I had messed up
osmo-hnbgw, but then I found out it wasn't my fault at all.
Related: Iea1824f1c586723d989c80a909bae16bd2866e08 osmo-hnbgw
Change-Id: Idb3f2398c934a1d785e8ee7913c12c0f289c1f18
Since I introduced stricter timeouts on PFCP messages in
hnbgw: add f_pfcp_expect()
commit 6bbfe057af
Change-Id I2117475b695d486b1204d61e5bb21120a6187354
the HNBGW tests with PFCP support fail often:
The Assoc Setup resending timeout (X26) is configured to 5 seconds, and
the timeout to wait for this is also 5 seconds. Every once in a while
they happen to miss, causing a test failure.
Increase the initial Assoc Setup Req timeout to 15 seconds to avoid
sporadic failures.
Change-Id: I4b9af224e2346a4735f3d4e01b234acf56c5f3ff
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
Vadim Yanitskiy
Philipp Maier
Pau Espin
arehbein
Daniel Willmann
Oliver Smith
Neels Hofmeyr
Harald Welte