If test calls RTPEM_bind twice, the previous socket is kept open
(ConnId 1) while the new one is assigned to the the expected ConnId for
RTP/RTCP packets received (ConnId), however, if remote was already
sending packets, it may happen that the port still receives those with
ConnId=1, which may make test fail with message:
"Received unexpected type from RTP"
Change-Id: I73f4af4e590dd3958e3f4d1dba0496c0750d642d
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
During MGCP_Test's f_flow_modify, an RTP socket may be Tx-enabled, and
f_flow_modify first calls bind, then connect, with MDCX transaction in
the middle (which can take some time).
If T_transmit from RTP_Emulation triggers (RTP packet to be send),
during that time, TTCN3 will fail to send the packet:
RTP_Emulation.ttcn:312 Message enqueued on RTP from system @Socket_API_Definitions.PortEvent : { result := { errorCode := ERROR_SOCKET (4), connId := 2, os_error_code := 89, os_error_text := "Destination address required" } } id 1
Change-Id: I20e7aed35bb28200e30ee5efc718f77e036d8262
The configuration of the RTP Emulation (RtpemConfig) allows to set a
fixed RTP payload that is then used when RTP packets are transmitted.
However, when packets are received, then the payload is not checked.
Lets check the received data against some user configurable rx payload,
that is by default set to the tx payload.
Change-Id: Id0b125aaf915497d0a4f051af890fc34e09da61d
Related: OS#3807
At the moment we check the error counters of the RTP statistics in
the testcases. However, in most situations we will do the check to
make sure that no errors occurred (all counters == 0). Rather than
having a long tail of if statements in the testcases we should have
a function for this. This also makes it much easier in case we add
more error countes lateron.
- add and use function f_rtpem_stats_err_check()
Change-Id: I69e5f80b0765284ec99056ce62c315461967d2a1
Related: OS#3384
When an RTP packet is received, the payload type is not checked,
so we will not detect if the MGW emits packets with a wrong payload
type for some reason.
- Introduce a statistics counter that counts packets with wrong PT
- Update testcases so that they check for the statistics for wrong
PT count.
Change-Id: I83d4b04656a16ced624024245a2fcb7a0ad48a8a
Related: OS#3384
This will prevent subsequent failures from overwriting the verdict so we
can easily see the root cause of the test failure.
Using testcase.stop instead for errors internal to our test
infrastructure to mark them as test errors instead of failed.
Change-Id: Idc6819aaf0b01e70c38fad828dd44dcec6bdd778
The test coverage of the RTP aspects of the MGW is currently very
minima. Lets add a few more testcase to verify RTP behaves as
expected in various situations.
- Add testcase TC_one_crcx_receive_only_rtp:
Test recvonly mode of the MGW. All packets must be absorbed by
the MGW, no packets must come back.
- Add testcase TC_one_crcx_loopback_rtp:
Test loopback mode of the MGW. All packet sent to the MGW must
come back.
- Add testcase TC_two_crcx_and_rtp_bidir:
We already test unidirectional transmissions. This test does
the same as TC_two_crcx_and_rtp but for both directions.
- Add testcase TC_two_crcx_mdcx_and_rtp:
Simulate a typical behaviour of a normal call. First create
two half open connections and complete the connections later
using MDCX.
- Add testcase TC_two_crcx_and_unsolicited_rtp:
Test what happens when a RTP packets from rogue source are mixed
into the RTP stream.
- Add testcase TC_two_crcx_and_one_mdcx_rtp_ho:
Test a typical handover situation. An existing connection is
handovered to another source on one end but the old source will
keep transmitting for a while.
Change-Id: I556a6efff0e74aab897bd8165200eec36e46629f
Closes: OS#2703
When sockets cannot be bound or connected, the existing TTCN-3 code prints
the following rather cryptic error messages:
"IPA-CTRL-IPA(47)@f70ff1fd5cfd: Dynamic test case error: Using the value of an optional field containing omit. (Transport endpoint is not connected)"
The "Transport endpoint is not connected" sort-of gives it away, but
let's make it more explicit by introducing explicit checks for the
res.connId and manual setverdict(fail) statements with proper error
message.
Change-Id: Id22a1b5189d81c4fca03d5e7aff60ffdd1ad56bf
The connection ID part of the template must be updated after we
created the respective sockets. It was done to early.
Change-Id: I37306d841df3d27d30fd89fb99c863370517e3ff