Project

General

Profile

Actions

Feature #2703

closed

extend mgw tests to test more actual RTP flows

Added by laforge over 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
12/03/2017
Due date:
% Done:

100%

Spec Reference:

Description

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 integrationResolveddexter09/18/2017

Actions
Actions #1

Updated by laforge over 6 years ago

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

Updated by laforge almost 6 years 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 4368 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.
Actions #3

Updated by laforge almost 6 years ago

  • Priority changed from Normal to High
Actions #4

Updated by dexter almost 6 years 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.

Actions #5

Updated by dexter over 5 years 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:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9768 MGCP_Test: add tests to verify actual RTP flows

Actions #6

Updated by dexter over 5 years ago

  • Status changed from In Progress to Resolved
Actions #7

Updated by dexter over 5 years 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: 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.

Actions #8

Updated by dexter over 5 years 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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)