The testcase ts_CRCX_no_lco looks at the media attributes to see
if it findes the expected default codec there. In this testcase
we expect PCMU/8000/1 as media attribute, but this is a codec from
the fixed payload type domain. The MGW may not list this info inside
the media attributes. Listing the payload type number in the media
description is sufficient. We should check this instead.
- Remove media attribute check
- Check meida description for PCMU (0)
Change-Id: I69600a1025e68011e8fc5d8bf22d842d9c63bf53
Related: OS#2658
As we are about to finish the implementation of GSM TS 09.11, in
our case it is 'SS/USSD over GSUP', OsmoMSC will not decide itself
which USSD request-code is known, and which is wrong.
Change-Id: Ic104a49bb2dce2127063bcef8443ee6b639c9f19
The 'SS Info' IE is optional for GSUP_PROC_SS_{REQ|RSP} messages,
and is not carried in some cases, e.g. when a subscriber aborts
an active transaction by pressing the 'red button'.
Change-Id: I20d9028acbe0c457d2a2cf72eff372b749d8dc30
According to GSM TS 04.80, table 2.5, the Facility IE is optional
for RELEASE COMPLETE message. So, if this IE is omitted, then the
whole TVL shall be omitted. It's time to fix this.
Change-Id: I216195ef71c95997708dad8c31b172b6f6cdc461
According to GSM TS 04.80, table 3.4, the Return Result component
may be empty, i.e. may not contain any results nor operation code.
It is used, for example, in responce to the network-originated
USSD notification.
Change-Id: Iaaff110c5f61cc87eda6143cd841f9832f6074bf
Until now, the test went from RR Handover Command directly to RR Handover
Complete, and osmo-bsc didn't mind it. However, the normal handover procedure
requires an RSL Handover Detect to be sent in-between those. Send that.
Change-Id: I6e54edcc3a99e116d852eca8e48c7a5bc685e832
The intention is to ignore RLL REL requests, and not to actually block the alt
statement in f_expect_chan_rel() if any RLL REL messages show up.
Change-Id: I3bbcdc41d186a3464cd4adb5c5b770bdec056993
Going via GSUP_Emulation (rather than using GSUP_CodecPort directly)
adds many benefits, such as:
* ability to have multiple transactions in parallel
* no silent discard/ignore of unexpected GSUP messages, like those
for IMSIs we don't expect.
Change-Id: Id2ddd6b81c374ad6350b62fcc5442436757d66cd
Those test cases simulate a BTS-originated RLL CONN FAIL IND at
"unusual" time:
a) before we actually establish any RLL
b) after / while we're tearing down the RLL
This is triggering an osmo-bsc segfault, see OS#3182.
Change-Id: I324c410d7565c189dbc91df577d92b87c036732c
Related: OS#3182
There's a sequence of commands which was repeated over at least
four test cases. Let's factor this out into the new
f_exp_chan_rel_and_clear() function, and use that function from
all the former copy+pasted sections.
Change-Id: Ic6791fce4e8787e38b818a12ed526d3e47f313ef
Previous the old entries aren't removed. This only had an
impact if two different f_TC_* were using the same imsi.
When the second function tried to remove the Client again from
the ClientList, the BSSGP_Emulation failed.
Change-Id: I71103e8f8c5f18e8ebadc057cd62d85affd7ca8c
MS <-> SGSN: Attach
MS -> SGSN: Detach Req (Power off)
VTY -> SGSN: Check if MS is NOT in subscriber cache
Change-Id: I0956d54760f19ca556fa0d16ea4c5b96ac13f2fa
PARALLEL | VERDICTOP will log when the port is dying or when other
components will change to fail. This helped to find a timeout in the
SGSN tests where a function call message timed out.
Change-Id: I770ac964dc37e2752e7d35e493f707b091c739b0
as of Change-Id Change-Id: I4f51abdf44dfc62d7e8792341aad6dafe58923da,
osmo-hlr passes HLR_Tests.TC_gsup_sai_err_invalid_imsi
Change-Id: I72fb71806c72ce29e8c6c9b25723f02009463cec
In this test case, the MSC performs a hard SCCP release of the
SCCP connection. This makes the BSC send a RLL REL REQ on the lchan,
but we simulate a broken/lost MS which doesn't respond to that.
Current OsmoBSC master will fail this test, and that's exactly why we
need it.
Change-Id: I800168499c2ab30af72625aba6fc740bc16e5653
Related: OS#3333
This test establishes an SDCCH for each iteration. However,
* due to OS#3333, osmo-bsc is currently not properly releasing those
lchan's,
* due to OS#3222, we furthermore don't allocate "larger" channels like TCH
and as a result on a combined CCCH system we only have 4 SDCCH, which
is less than the 8 that we try to use here.
Change-Id: I0f7fff54248a505387bdfe105259e8ad10ce6c77
Related: OS#3333
Related: OS#3332
For each of the SCCP/BSSMAP connections we create, let's make sure we
use a different RA and frame number, to make sure the test is more
realistic, and to aid any debugging.
Change-Id: I35540979c38d46f03702812e93742d7db772c533
While osmo-bsc was still affected of OS#3331, it would release the SCCP
connection from the BSC side. This is illegal as per 3GPP spec and
has meanwhile been fixed in osmo-bsc master. However, the testcase
BSC_Tests_LCLS.TC_lcls_connect_clear() relied on the broken behavior,
let's fix that.
The testcase now releases the SCCP connection from the simulated MSC
side in response to the BSSMAP Clear Complete from the BSC.
Change-Id: Ic3e1f8729a093b04941ec7ca72664d53adb21229
The existing test simply sent 1000 messages via RSL without checking
what actually arrived on the radio interface, or without
expecting/counting any RSL DELETE IND.
Let's fix this by introducing test sending IMM.ASS at three different
rates, with related expectations in terms of nubmer of IMM.ASS arriving
on Um vs. RSL DELETE IND arriving at BSC.
Change-Id: Ib6043b76ba1d7aaff107bb612f63b5a747d8720c
Related: OS#2990
Related: SYS#2695
The idea of this testcase is to check if MSC can correctly
handle a USSD-request during an active call.
What we do here:
1) Perform Location Update
2) Establish a MT-call
3) Perform *#100# request
4) Release the call
Change-Id: Ifa3cd1aeeb34ccf5864f78b76a88aaa6d5e51839
The idea of this testcase is to check reaction of the network on
reception of USSD request with unknown/unhandled request code.
It is not clearly defined by the GSM specs, how the network
should react in such cases, but looking at GSM TS 04.80,
section 4.3.2 "Error types description", the UnexpectedDataValue
error looks suitable. Commercial networks also use this error
when an unknown request code is sent.
Change-Id: I6a3fcaafc37972a38c13722f0b511ea5e1e3fbd8
When a CRCX without an LCO option (codec) is sent, then older versions
of osmo-mgw will omit the port number in the SDP part of the response.
Also no default codec is selected and reported back. This testcase
pinpoints the problem.
Change-Id: Ie16cdab936ce468fe378d4ec9e1c61f81c07fb4e
Related: OS#2658
The osmo-mgw now rejects multiple appearances of LCO, the testcase
TC_crcx_illegal_double_lco now passes.
- update expected-results.xml
Change-Id: If4a68e9373b34696236935cce936e9d3c254511b
Related: OS#3119
When f_ass_patch_lcls() was recently introduced during LCLS support
patches, we broke any testcases that *expected* an ASSIGNMENT FAIL
by overwriting the ASSIGNMENT FAIL with an ASSIGNMENT COMPL.
This patch fixes f_ass_patch_lcls() to only patch 'assignmentComplete'
members, if this assignmentComplete is actually chosen.
This fixes BSC_Tests.TC_assignment_fr_a5_1_codec_missing
Change-Id: I64fbf4cc3178a91913143960475a0d3758779ced
The omit force this field to be not present, while a * allows to be present or not.
As user of this tr I would expect to ignore this field rather than an explicit omit.
Change-Id: Iae91f752789273934a6382bdd474594c3c50bbe9
This is an early WIP, we actually will need to establish two calls/legs
before the BSC is able to locally correlate them.
Related: OS#1602
Change-Id: Ie6d0b9c38027abf65c7c564fc79b889d013fa6a7
Neels Hofmeyr
Philipp Maier
Harald Welte
Pau Espin