Until now we forgot to properly configure the osmux socket local ip, but
that was fine because 0.0.0.0 was taken as a default.
With addition of IPv6, this changed, and the socket is not bound unless
an IP address is set (to allow conditional use of IPv4, IPv6 or both).
Depends: osmo-mgw.git Change-Id I446cd7da217e9f4a74995d7784ae55dcc60a29b7
Change-Id: I4e0ea11ae7e55da600aec56bebf694f3ba0f7b72
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
Set the executable name in each regen_makefile.sh explicitly with -e,
instead of having it set indirectly from the first .ttcn file. Make it
consistent by placing the name on top of each of these files.
Fix for warning:
ttcn3_makefilegen: warning: File `BSC_Tests.ttcn' was given more than once for the Makefile.
Related: OS#5252
Change-Id: I5ed03f8f3ed905483620dc7bae33b617bbb8507f
Make all regen_makefile.sh more readable and diff friendly by moving
each entry in FILES and CPPFLAGS_TTCN3 into separate lines. Order
entries alphabetically.
Related: OS#5252
Change-Id: I6b6866eb9f6ec6232e4ae434517457a4c8c1c050
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
The recently added test TC_dlcx_wildcarded depends on statsd information
from osmo-mgw but in the osmo-mgw configuration no statsd is configured.
Change-Id: I35e07a6b1853234559ab4d7e044f3899e8d0a3e8
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
The .cc and the .ttcn file of RTP_CodecPort_CtrlFunct is currently
copied into the mgw directory and then used. However, those files do
exist in the /library folder as well, lets just link them using
gen_links.sh
Change-Id: I14f80051f6a168b7a8155c6e523c085e974b62b5
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
Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
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
Pau Espin
Neels Hofmeyr
Philipp Maier
Oliver Smith
Neels Hofmeyr
Harald Welte
Daniel Willmann