Change in osmo-ttcn3-hacks[master]: msc: overhaul voice call testing

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

neels gerrit-no-reply at lists.osmocom.org
Wed Nov 13 16:52:50 UTC 2019


Hello pespin, Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15938

to look at the new patch set (#3).

Change subject: msc: overhaul voice call testing
......................................................................

msc: overhaul voice call testing

* Semantic:

We don't really know which side the MSC first creates a CRCX for. Instead of
assuming that the RAN side is always CRCX'd first, simply handle a "first" and
a "second" CRCX, not making any assumptions which is for which side.
Notably, there still are quite a few places assuming which CRCX corresponds to
the RAN/CN side, but the changes are sufficient to still pass the tests when
osmo-msc swaps the CRCX order; sometimes for slightly obscure reasons, for
example because it doesn't matter that the wrong port number is returned during
a subsequent MDCX... Cleaning up the rest is still todo for later.

Remove code dup from call establishing code, particularly for MGCP.

Use f_mo_call_establish() and f_mt_call() where ever possible, to make all of
the call establishing tests handle upcoming changes in osmo-msc's order of
messages, without re-implementing the changes for each test individually.

The X-Osmux parameter was so far expected to appear in the first CRCX received,
assuming that this first CRCX is for the RAN.  Instead, detect whether X-Osmux
is contained in a CRCX, and reply with an Osmux CID if so, regardless of it
being the first or second CRCX.  Count the number of X-Osmux parameters
received in CRCX messages, and compare after call setup to verify X-Osmux
presence.

Since f_mo_call_establish() can't handle RANAP assignment, a few Iu tests that
worked with the older code dup will break by this patch. This is fixed by a
subsequent patch, see I0ead36333ab665147b8d222070ea5cf8afc555ec.

* Details, per patch chunk:

Change ts_BSSMAP_IE_AoIP_TLA4 to a non-value template, so that we can use a
wildcard for the assigned port number from MGCP (depending on RAN or CN CRCX
first, the RAN port number can be one or the other).

In CallParameters, move MGCP handling instructions into a separate record
"CrcxResponse", and have two of them for handling the first and the second
CRCX, replacing mgw_rtp_{ip,port}_{bss,mss} and mgcp_connection_id_{bss,mss}.

In CallParameters, add some flags for early-exiting call establishment with a
particular desired behavior, for specialized tests.

In CallParameters, use common default values and don't repeat them in each and
every call establishing test.

Set cpars.mo_call := {true,false} implicitly when f_{mo,mt}_call_establish()
are invoked.

Remove CRCX comments implying RAN or CN side, instead just talk of the "first"
and the "second" CRCX.

Implement one common f_handle_crcx() function, which is used by
f_mo_call_establish(), f_mt_call_complete(), as_optional_mgcp_crcx(), and
implicitly uses the first/second CRCX handling.

For Assigment, use a wildcard RTP port so that we don't have to assume which
CRCX was for the RAN side.

In f_mo_call_establish(), insert special case conditions to make it enact
errors at specific times, for individual tests. That saves re-implementing the
entire call establishment (code dup).

For error cases, add expectation of a CC Release message in the call
establishment. This should not apply for normal successful operation, but
because interleave does not support conditionals, add flags
got_mncc_setup_compl_ind and got_cc_connect to break the interleave when
establishing is complete, so that the CC Release is skipped.
A CC Release always breaks the interleave, at whatever time it arrives.

Tests adopting f_{mo,mt}_call instead of code dup:
  f_tc_mo_setup_and_nothing()
  f_tc_mo_crcx_ran_timeout()
  f_tc_mo_crcx_ran_reject()
  f_tc_mo_release_timeout()
  f_tc_mo_cc_bssmap_clear()

Change-Id: I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
---
M library/BSSMAP_Templates.ttcn
M msc/BSC_ConnectionHandler.ttcn
M msc/MSC_Tests.ttcn
3 files changed, 292 insertions(+), 335 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/38/15938/3
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15938
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
Gerrit-Change-Number: 15938
Gerrit-PatchSet: 3
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: laforge <laforge at osmocom.org>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20191113/ebf5b71d/attachment.htm>


More information about the gerrit-log mailing list