The function f_check_mgcp_expectations() checks the counters that
count the occurrence of MDCX and CRCX messages against computed
expected values. At the moment it is not easy to spot where exactly
the deviation occurred. Lets add some log output so that we can see
which type of message on which connection was missing or too much.
Also add a string parameter that is set to the calling functions
name so that we know from where the check has been triggered.
- Add more verbose log output for counters
- Add parameter to prepend to the log line
Change-Id: Ida0eba4ef3c1db977d392267ef76ec37b87133b3
Related: OS#3292
The function f_establish_f_establish_fully does not yet handle the
case where calls get switched locally. In those cases we expect to
see one additional MDCX before the BSSMAP ASSIGNMENT COMPLETE is
sent.
- Check exp_ass_cpl if the call is expected to be LCLS and expect
another MDCX for those cases.
Change-Id: I55fae5ab03980cd810ed7dc38208550686b1659e
Related: OS#3292
as_media handles the MGCP interaction for most of the tests. However,
it does not make sure if transactions are missing or if too many
transactions are performed (e.g. if an SCCP-Lite tests still creates
the connections pointing to the core network, even if they must not
created by the BSC in this case). So lets make sure that the MGCP
transactions are performed as expected by counting them.
- Add counters to count CRCX and MDCX transactions
- Check those counters after call establishment and handover
Change-Id: Ib073b097a840ca3a8ee99c4ed41f59f574191d98
Related: OS#3292
as_media() tests both, IPACC/RSL media handling and MGCP media
handling. These two domains are technically quite separate, which
means we can split them up into two separate altsteps in order
to increase readability of the code.
- Split as_media() into as_Media_ipacc() and as_Media_mgw()
Change-Id: I539e8ffdb9f99d5a8e730dd918df502614b9e84d
Related: OS#3292
The current osmo-bsc refactoring causes an erratic MR Config IE. This patch
ensures that the ttcn3-bsc-tests catch this error.
Add MR Config IE expectations to g_pars, set these in the two tests that expect
an MR Config IE in the Chan Activ message:
BSC_Tests.TC_assignment_codec_amr_{f,h}
All other tests now verify that there is *no* MR Config IE in RSL Chan Activ
messages -- all other tests request no voice or a non-AMR codec for Chan Activ.
Change-Id: Ie841feed9d5e478bab1fea2bb86f300e84799013
The test currently use a hardcoded payload type and encoding name.
This does mean in practice that even when an assignment with EFR
is happeining. The MGCP responses to the BSC tell that the codec
is AMR. This is not correct. The testcases should always pick a
suitable payload type / encoding name in the MGCP response
- Add constants for IANA/3GPP assigned payload types
- Add function to lookup the right encoding name for a payload type
- Initalize the encoding name and payload type in g_media according
to the BSSAP PDU.
Change-Id: I2735267091059e2f2169da80bdcd30abc2b1554b
Realted: OS#2728
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
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
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
The helper function f_establish_fully() checks the channel type
for compatibility. If the channel type is compatible with the
desired mode a channel mode modification could be necessary if
the current channel mode is different from the desired channel
mode. However, this is not checked at the momemend. We just
blindly expect a MODE MODIFY message from the BSC and ignore
the cases where the current channel mode and the desired channel
mode already matches up. This is the case if only a signalling
channel is requested with f_establish_fully for example.
- Check if the channel mode of the current channel and the
desired channel mode match up.
- Make sure that the MODE MODIFY from the BSC is only
expected when the channel modes are different.
Note: The function f_channel_needs_modify() that is used
to determine if a channel modification is needed or not
does not cover all cases yet. (see fixme note)
Change-Id: I9004f299220b01ecea6b2316ba3f913c316947dc
Closes: OS#2762
Related: OS#2936
If it's a pure signalling procedure (like LU), the MSC will never
even send a BSSMAP ASSIGNMENT CMD. Our test suite should be able
to produce this kind of behavior by passing "omit" as assignment
comamnd to the f_establish_fully() function.
Change-Id: I9bb5c8c19518905cf1ce121aa0b433886ec594d5
Make sure that the "tag" member of the RslChanelNr sub-structure
is always initialized. This can be achieved without any extra code
by using the existing templates rather than hand-coding it.
Change-Id: I990ac8ac0ce51e11f1d683382c9fc2d4e1201aa7
The problem is that Junit-XML doesn't have a mapping for inconclusive
results, and hence they show up as 'passed'.
By introducing this change, we make sure all tests that don't pass
show up as failed.
Change-Id: Iddd13d0055c91f9bd304ce9833fba0485abf4c4e
The altstep as_handover does not exit as each of its branches is
equipped with a repeat statement on the end. This trapps us in
an endless loop.
- remove the repeat statement at the last logical step which is
at the RSL_REL_REQ.
Change-Id: I8cb57a9fef606f459542708206f5ea4de1def7a1
This allows each ConnHandler to issue telnet commands to the VTY
As a side-effect, it puts some more stress on the VTY interface,
as each [parallel] DchanHdlr now has its own telnet connection.
Change-Id: Ibd726af53219d829286da80b44ea4d9fb2ffdf3d
A problem with the parameter ordering inside the mgcp-client
(osmo-mgw) prevented TTCN3 from accepting the SDP data that
was generated by the IUT. The problem is now fixed and the
hack can be removed.
- remove hack
Change-Id: Ic37f78c2676e7c98144f10e9f3b55bc9651a4f7c
Related: OS#2818
The representation of the chiphering algorithm is different bssmap
and RSL. BSSMAP uses a bitmask and RSL a numeric value. For A50 and
A51 the values match up by coincidence, from A5/2 onwards they differ.
- Add a function to convert the BSSMAP representation to the RSL
representation and use the converted value to set up the temlate
for the expected RSL message
Change-Id: I274c1ff0b5636c48411f994f918e783b468cb3be
The altstep guard statements are to restrictive so they do not
match on an expected assignment failure anymore.
- Add a new altstep for expected assignment failures.
Change-Id: I78b839f0bcb7e2da61bff0add3abc452bfea40a2
MGCP permits for the CallAgent to send a wildcarded endpoint name,
at which point the MGW itself must allocate an endpoint name and
return it as SpecificEndpointId parameter in the CRCX response.
Change-Id: I704bbe4e11b27e83a6ae6a71aa6a715dc8301f34
We shouldn't "pass" f_establish_fully() in the assignment case
as long as the old RF channel hasn't been released via RSL.
Change-Id: If7c7c8c4826feba47f8a0395c291157a0e48cd9d
This adds code for the rather intricated and nested transactions
happening on RSL, BSSAP, MGCP and RSL-IPA. We use explicit
invocation of altsteps to simplify the main function f_establish_fully.
Change-Id: I5f830b010ea1b466ae74fa810df86638a74a3b8b
It's quite cumbersome if the user of the BSSMAP_Emulation (the ConnHdlr)
will have to manually decode the DTAP in every BSSAP/DTAP message he
receives (and encode on the transmit side). Let's introduce a new
optional mode in which the DTAP messages are already decoded for
more convenient matching inside the ConnHdlr.
Change-Id: I35cd4ea78aca0ce7c7d745e082d7289882c11e81
Don't expect the ASSIGNMENT to fail in case of unsupported A5/4,
but expect a CIPHERING MODE REJECT.
Change-Id: I15024f61e67795b7e5ce72e1b641db6ca92ff76d
For some weird reason the link_id is *not* the second IE in
RSL_MT_ENCR_CMD, while it is in all other RSL RLL or DCHAN messages.
Change-Id: Iea93aa8dba74d25c74a257d011ba43308ee375e4
In all RSL messages the link identifier is usually the second IE.
However, as the only known exception, the RSL Encryption Command has it
as third IE.
Fixes the following error message:
Dynamic test case error: Using non-selected field link_id in a value of
union type @RSL_Types.RSL_IE_Body
Change-Id: I2bbb83b5394d0b693a47d286beed5c699ab6e8ae
Let's verify the operation of the CIPHERING MODE COMMAND as issued
by MSC, performed by BSC and implemented by simulated BTS/MS.
Change-Id: Ibc06bd2177c63837a794a0ca1f54ebef17499e78
Using the MSC_ConnHdlr component, we can now handle the BSSAP (MSC)
and RSL (BTS) side of a single radio channel.
Change-Id: I00dcf1e4eaa7f133788cc01fbbcd4148a0258ef4
So far, BSSMAP_Emulation used the SCCPasp_SP_PORT directly, explicitly
calling BSSAP encode/decode functions while processing the primitives.
Let's clean this up and use the BSSAP_CodecPort which has meanwhile
been developed as a dual-faced port that can be stacked between SCCPasp
and the user to avoid any manual encode/decode function calls.
Change-Id: Icded789d18f3469f74e16f552df2c7ac44ac4294
Neels Hofmeyr
Philipp Maier
Harald Welte
Daniel Willmann