extend mgw tests to test more actual RTP flows
So far, the mgw tester in osmo-ttcn3-hacks is testing MGCP signalling only, not yet any RTP flows. This needs to change/improve
- Subject changed from extend mgw tests to test actual RTP flows to extend mgw tests to test more actual RTP flows
- Assignee changed from sysmocom to dexter
The test contains one testcase that tests RTP,
TC_two_crcx_and_rtp which can serve as an example. However, we're not yet testing e.g. MDCX operation in presence of RTP flows.
- RTP packets from other source address/port than the connected address must be ignored and not passed to the other side of the RTP bridge
- after a MDCX, packets from the old address/port (before MDCX) must be ignored/discarded, like above. only the new ip/port must be accepted.
- % Done changed from 0 to 80
I have now tests that cover:
- a normal bidirectional call (two times CRCX first half open, then MDCX to make call complete)
- a situation where an unsolicited source sends RTP packets (MGW ignors them)
What still missing is is a handover situation where the connection is first created normally and then handovers, but the old source keeps transmitting. I will do that next.
- Status changed from New to In Progress
- % Done changed from 80 to 100
I have now added the handover situation. The patch is now in gerrit:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9768 MGCP_Test: add tests to verify actual RTP flows
- Status changed from Resolved to In Progress
- % Done changed from 100 to 90
For the RTP streams that inject the unsolicited packets I used hardecoded IP-Addresses. This may be part of the problem. We should use the modulepar parameters here.
See also: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9787 MGCP_Test: do not use constant IP addresses
But this does not solve the problem. I do not know what exactly it is yet. For some reason now and then some packets which are not indended for RTP_Emulation.ttcn arrive at the end of the altstep in f_main(). I even saw MGCP responses from the MGW ending up here. I have observed this behavior locally from time to time, but the occurrence is very rarely. The failure of might have to do something with that TC_two_crcx_and_unsolicited_rtp and TC_two_crcx_and_one_mdcx_rtp_ho, but it is very suspicious that exactly the two tests fail where I inject undissociated packets. Maybe I am also doing something wrong when setting those streams up.