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
When setting up an RTP flow the fmtp string is checked using isvalue(),
however this does not guard against empty fmtp strings. Rejecting empty
strings is especially useful in situations where the caller wants to
signal using "" that no fmtp string is present.
Change-Id: I2641a52a3b271681f4f2e424c34be12e125092d6
Related: OS#5688
Add a test that uses SDP CLEARMODE towards the MGW. The SDP parameters
generated by the test look as expected when compared to RFC 4040
section 5.
Related: OS#4395
Related: https://www.rfc-editor.org/rfc/rfc4040#section-5
Change-Id: I89c5dfdcd728ab3b50e77c5062f07e1b802b1f01
The tests that test the conversion from AMR octet-aligned to AMR
bandwith-efficient use the same payload type number on both ends. This
does match the reality. Typically the BSS uses 96 as payload type
internally, while 3gpp specifies a payload type of 112 on the link
between BSS and CN. To reflect those conditions in the test as well,
lets use 96 on one RTP end and 112 on the other.
This also increses the test coverage as we now test if PT translation
and bwe/oa conversion work together.
Change-Id: Id734b6954098130bba02f8cdf1b06e0080c3e915
Related: OS#5461
Previously the test was starting to count Osmux packets too early.
Now that osmux conn state has been improved in osmo-mgw [1], Osmux
Rx packets are not forwarded until the conn is completely configured
through MGCP, hence first osmux packets snet by our async emulation
are dropped.
So we must start counting the transmitted valid osmux packets according
to what the test says, when the full conn is set up.
[1] osmo-mgw.git Change-Id I7654ddf51d197a4107e55f4e406053b2e4a02f83.
Related: SYS#5987
Change-Id: I7efd87bbbda2ffa8fd0c5a64658d42edd0f30857
Since osmo-mgw.git 2177919edb3bc0dd308be388272486ffd97f4761, osmo-mgw can handle
properly conns containing a different remote and local CID.
Hence this hack can be dropped.
Related: SYS#5987
Change-Id: I531631d716581f68c11d3c0b07fc6755a822a0d3
Some tests require to match what's configured in osmo-mgw.
Let's make it possible to change it through a module parameter.
This will be needed for a follow-up patch to test >256 concurrent osmux
conns, which will require increasing the number of configured endpoints
above that value.
Change-Id: Ia1e5a0b59ba7c49e97c2cf7ee7a009f3827cf36d
We are currently testing the behaviour of wildcarded DLCX on the virtual
trunk. Lets run a similar test on the E1 trunk as well.
Change-Id: I6cfbd24982d1e72206f8237b2eaea52cdaebf9dc
Related: OS#5572
When the final condition of the testcase is verified through statsd,
there may be still (invalid) data from a previous measurement in the
statsd pipeline, querying the stats once before verifying the actual
stats fixes the problem.
Change-Id: I5fe18e433b32c364778b515ed37fcbcf443b3cb3
Related: OS#5572
Due to the migration to a multithreading scheme the timing behavior of
the stats items has slightly changed. There is now a 1 sec update cycle
in which the stats items are regenerated. This means we have to wait 1
sec. before we can query the endpoints.used stats item.
Change-Id: I90613616f9ff85ca59464dfd45d331ed1a54d9c5
Related: OS#5316
The module parameter mp_test_ip was added with the following commit:
Change-Id I61e23e264bc85eb36d07431c7839fb445c110947
There is already mp_local_ipv4, which has the same function, so we
should remove mp_test_ip again and use mp_local_ipv4 to set up the
receiving of statsd information.
Change-Id: I70f33aed4102c67118cc6701c2578a70c0dfe604
Related: SYS#5535
Since we now support wildcarded DLCX request, which so not necessarly
require a specific endpoint (the trunk is enough). We should also check
what happens when we send a DLCX request to a non existent endpoint. The
situation would be very similar. osmo-mgw will be unable to resolve the
endpoint, but the trunk will be resolved. However eventually the request
is not wildcarded and we expect that osmo-mgw is rejecting it.
Change-Id: I3d8c6f84404c1c95f97f113813528175523d36b8
Related: SYS#5535
The testcase TC_one_crcx_loopback_rtp_implicit triggers a bug in older
osmo-mgw version that eventually leads into a crash of osmo-mgw. This
also means that all tests after TC_one_crcx_loopback_rtp_implicit will
also fail. Lets move TC_one_crcx_loopback_rtp_implicit to the end of the
control section to postpone the crash to the very end of the testrun.
Change-Id: I25abf30f8c49e580c46e7a61e887bd0add9a4cd4
Related: OS#5123
The testcase TC_one_crcx_loopback_rtp_implicit uses
f_TC_one_crcx_loopback_rtp, which creates the RTP flow with IPv4
addresses but since we do not send a local RTP IP address with the CRCX
to the MGW, the MGW will prefer IPv6, which means that we get an IPv6
address back while the RTP strem is IPv4 on the TTCN3 side.
Related: OS#5123
Change-Id: I80498737d5b32f28b62e0c17cce1969b54af948c
Test what happens when the MGW gets a CRCX that creates a connection in
LOOPBACK mode but does not specify an RTP destination address. The MGW
is expected to deduct the destination address from the first incoming
RTP packet and loop it back to its originating address.
Change-Id: I7baf827fb0c3f33e13ccbaffd37ba0eb4e20c304
Related: OS#5123
These tests verify that osmo-mgw handles requests no matter of IP
version used in the remote address.
Change-Id: Ib134dda5a8f7c8f50968b6ce330f9986ae72575d
Send the remote address to MGW so it knows which IP version to return
during CRCX ACK. This actually better suits the test, since there's less
point in checking whether we receive something if we never pass the
IP/port to MGW. In any case, the "recvonly" should still tell MGW to
refrain from sending stuff to us, so we are really testing that here.
Change-Id: Id3452cecf7fb281e5e46471f7f53983c08c6bfdf
rtpem should be set to BIDIR at the same time where MDCX "sendrecv" is
sent, otherwise if MGW sends us RTP packets (because we set the conn to
sendrecv) they will be counted incorrectly in
stats[0].num_pkts_rx_err_disabled.
This issue doesn't trigger in current code because the MGW doesn't know
anyway the remote IP address of the other connection until an MDCX is
sent to it. However, if for whatever reason the IP address is known (for
instance because it is set during CRCX, which will be done in next
commits), then RTP messages would be sent and the error counter would
be > 0.
Change-Id: I8f2c4e497e522fc17e5cfe76987f802265c486ab
rtpem should be set to BIDIR at the same time where MDCX "sendrecv" is
sent, otherwise if MGW sends us RTP packets (because we set the conn to
sendrecv) they will be counted incorrectly in
stats[0].num_pkts_rx_err_disabled.
This issue doesn't trigger in current code because the MGW doesn't know
anyway the remote IP address of the other connection until an MDCX is
sent to it. However, if for whatever reason the IP address is known (for
instance because it is set during CRCX, which will be done in next
commits), then RTP messages would be sent and the error counter would
be > 0.
Change-Id: I653eb75439321f9a488dc56dca5d3fc5a8811547
This will be needed once IPv4+IPv6 support is used, since we want to set
the remote IP addr in CRCX for convinience to get an IP adr from ther
same family during CRCX, while still allowing for testing Osmux CID
wildcard value.
Change-Id: I3abd80b1c0053004aab3d03e09fada1129a59765
osmo-mgw recently added support for E1 trunks via libosmoabis. While the
actual E1 plane may be difficult to test, there is some functionality
that can already be tested without having E1 support in TTCN3.
Lets add three testcases:
- TC_e1_crcx_and_dlcx_ep:
Does a CRCX to an E1 endpoint followed by a DLCX
- TC_e1_crcx_with_overlap:
Not all E1 endpoint combinations are possible at the same time. This
test verifies that invalid endpoint combinations are prevented.
- TC_e1_crcx_loopback:
Opes an E1 endpoint and tests if RTP loopback works (NO E1 traffic
involved)
Change-Id: I673eeffcb3012b42f039789960c54d99282e1aad
Related: OS#2659
The testcase TC_crcx_wildcarded_exhaust assumes a wrong number of
endpoints. Since osmo-mgw has a wrongly solved off-by-one in its
endpoint allocation it allocates the wrong number of endpoints. This
is now fixed, lets now also fix the test expection.
(The failure of TC_crcx_wildcarded_exhaust also causes
TC_crcx_dlcx_30ep to fail.)
Depends: Change id I73b31e3c236a61ea0a6f76ef5ff98ce589f52c77
Change-Id: I73344ef8793cc81df0a1815bb8d890e7849cdd20
Related: OS#2659
The rtp payload test vector in TC_amr_oa_bwe_rtp_conversion is wrong, it
lacks the last byte which should be 0x00. Also the testvector is not
very well chossen since it after BWE conversion the actual payload does
not shrink (even if it looks like if it would because of the 0x00 byte
at the end). Lets pick a better payload from a real world trace that
actually shrinks by one byte when it is converted to BWE and use that
one.
Change-Id: Id4256049bbca49ad5c2eb0579128838ebae062f8
The endpoint number of a virtual endpoint must not use leading zeros
but, but the testcase MGCP_Test.TC_crcx_dlcx_30ep does. Lets not do this
as it violates the spec. See also: RFC 3435, section E.3.
Change-Id: I99d2fa76cb60d0d671c9413f3dbd711ec68aeb77
Related: OS#2659
Latest osmo-mgw release is 1.7.0, so this param is not needed at all.
Furthermore, the config can be moved to .cfg.
Change-Id: I537c0f5fd6f9e18e111c773c0e42e5f1120ce2f4
The testcase TC_ts101318_rfc5993_rtp_conversion tests the RTP packet
format conversion of ts101318 to rfc5993 and vice versa. At the moment
the testcase sends RTP packets in both directions at the same time. In
order to simplify the test and to make race conditions less likely, lets
test both directions separately and add some guard time.
Change-Id: Id9b69587f7fb5f6b0da072ac5f4863fd4111e597
The testcase TC_one_crcx_receive_only_rtp performs a short RTP
transmission that lasts about 1 second. Then it conuts out the number of
packets that are transmitted and checks against a fixed value. The
compare values are determined using experimentation and reflect the
number of bytes/packets that one could expect under normal conditions on
an average machine.
However, there may be load sitations on the test host that may cause that
a too little number of packets is transmitted and the test will fail. Lets
reduce the number a bit as the only thing we want to make sure with this
is that there are at least some (more than one or two) packets transmitted
Change-Id: Ie63445d61268d178940ce8d9cfa984519c42041a
The following testcases are carried out using two bidirectional
connections on one MGW endpoint.
MGCP_Test.TC_amr_oa_bwe_rtp_conversion
MGCP_Test.TC_amr_oa_oa_rtp_conversion
MGCP_Test.TC_amr_bwe_bwe_rtp_conversion
The test is programmed in a way that the TTCN3 side of the RTP emulation
also works in bidirectional mode. This is prone to run into a race
condition when the RX side is activated but the TX side is already
transmitting.
However, in order to test if the RTP format conversion works we do not
need to test both directions at the same time. Its perfectly fine to do
the one direction first and then do the other afterwards. Lets also add
some guard time while switching the RTP flows.
Change-Id: Idf257cfc1ab45a7f0fb6e1a2f6426f1b3145879b
Fix ttcn3-mgw-latest by not running "conn-timeout 0" during f_init_vty
at the start of every test case. The latest osmo-mgw release does not
have that command yet.
Change-Id: I8bbf15baa45679d5812a5a9184520ef9b9e73bba
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
osmo-mgw now implements a conversion between the AMR octet-aligned
and banwith-efficient payload format. Lets add tests for this
Change-Id: I050bfeabfb5fdbf986d429eef3af69fe8158d56e
depends: osmo-mgw I622c01874b25f5049d4f59eb8157e0ea3cbe16ba
related: SYS#4470
Philipp Maier
Oliver Smith
Pau Espin
Harald Welte
Daniel Willmann