osmo-mgw should not respond to unknown peers. The test expected the
wrong thing, because of an old hack for 3G voice. Fix that.
Related: OS#6424
Change-Id: Ibe2ee59d1ed2c25ffef7e8534c172ac190b4983d
was added with mismatching indent in
"mgw: Update to contain similar config from docker-playground.git"
commit cec73acdd4
I2aa4d86e548d6644f1dd9358f6b8b48a19c96c3c
Change-Id: I5d4d1af40410bfdcc1280f45b85a8ae0c7b94a80
The test uses two connections: "confecho" and "sendonly". It is expected
that "confecho" connection receives as many RTP packets as it sends,
because it echoes back its packets. It is also expected that "sendonly"
connection receives the same amount of RTP packets.
Change-Id: I7df4a58ad9287a564b2daf7548b882c03787f7f2
The testcase TC_one_crcx_loopback_rtp_implicit creates a loopback
connection using CRCX but without SDP. It selects AMR using LCO. The MGW
responds with an MDCX and acknowledges AMR with a payload type of 112,
The TTCN3 testcase then sends AMR RTP packets with payload type 111, those
are accepted and looped back but the payload type will be converted to 112
as negotiated in the CRCX response. However the TTCN3 test still expects
111 in the packets comming back from the MGW. This is obviously a wrong
expectation and the testcase did only pass because Osmo-MGW was behaving
incorrectly.
To fix this let's just use 112 as payload type as payload type in this
test. This is the recommended payload type number for AMR (3GPP TS 48.103,
Table 5.4.2.2.1) and used by the MGW by default in case the call agent does
not specify a different one in SDP.
Change-Id: Idc370e9dc2e4954374fc7d07f7b117788028635a
Related: OS#5461
The octet aligned to bandwith efficient conversion is currently only
tested in scenarios where only one codec is assigned on both sides.
However, there may be call agents that will assign bandwith efficient
and octet aligned on one side for compatibility reasons. If this is the
case, then OsmoMGW should always chose the format that requires no
conversion.
Related: OS#5461
Change-Id: I2b2d7ef7fb4fe31111aa8665c4d4295425502451
The template RtpFlowData is defined in the middle of the code, lets move
it up below the related record definition
Change-Id: If854f708e4da8b3a7b02d1ace2eb7caa3e2f2bfb
When creating a flow with fmtp parameters we must always add them in a
second step. Lets update t_RtpFlow, so that it supports fmtp as an
optional parameter.
Change-Id: I04b17c0d233c1db4b9ba1306a4e0555914519bf8
At the moment The RTP emulation and MGCP_Test only allow to specify one
codec and one set of RX/TX fixed payload octet strings to verify against.
This is quite limiting since it might be necessary to test against
different types and formats of payloads simultaneously in order to see
if osmo-mgw converts or forwards them correctly.
Let's extend this to support multiple codecs on MGCP/SDP level plus
support for multiple RTP payloads on RTP emulation level.
Related: OS#5461
Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
The function f_TC_amr_x_x_rtp_conversion() is called with RTP payload
octetstrings in the parameter list. Lets define constants for those
octetstrings so that it is better visible which RTP payload is which.
Change-Id: I7efc22e2f8a941e36200dda7841089e6c97185c6
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
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
Neels Hofmeyr
Harald Welte
Pau Espin
Andreas Eversberg
Philipp Maier
Oliver Smith