Feature #2703

extend mgw tests to test more actual RTP flows

Added by laforge 8 months ago. Updated 14 days ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


So far, the mgw tester in osmo-ttcn3-hacks is testing MGCP signalling only, not yet any RTP flows. This needs to change/improve

Related issues

Related to OsmoMGW - Feature #2516: automatic testing of osmo-mgw / jenkins integrationResolved2017-09-18


#1 Updated by laforge 8 months ago

  • Related to Feature #2516: automatic testing of osmo-mgw / jenkins integration added

#2 Updated by laforge 2 months ago

  • 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.

We're also not yet testing
  • 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.

#3 Updated by laforge 21 days ago

  • Priority changed from Normal to High

#4 Updated by dexter 20 days ago

  • % Done changed from 0 to 80

I have now tests that cover:
- loopback
- rx-only
- 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.

#5 Updated by dexter 19 days ago

  • 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: MGCP_Test: add tests to verify actual RTP flows

#6 Updated by dexter 19 days ago

  • Status changed from In Progress to Resolved

#7 Updated by dexter 18 days ago

  • 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: 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.

#8 Updated by dexter 14 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

I see the patches are merged now. The test results are better than I expected. Only TC_two_crcx_and_one_mdcx_rtp_ho occasionally failes.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)