https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-12-03T11:14:47ZOpen Source Mobile CommunicationsOsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=65112017-12-03T11:14:47Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed" href="/issues/2516">Feature #2516</a>: automatic testing of osmo-mgw / jenkins integration</i> added</li></ul> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=92432018-05-09T10:17:44Zlaforge
<ul><li><strong>Subject</strong> changed from <i>extend mgw tests to test actual RTP flows</i> to <i>extend mgw tests to test more actual RTP flows</i></li><li><strong>Assignee</strong> changed from <i>4368</i> to <i>dexter</i></li></ul><p>The test contains one testcase that tests RTP, <code>TC_two_crcx_and_rtp</code> which can serve as an example. However, we're not yet testing e.g. MDCX operation in presence of RTP flows.</p>
We're also not yet testing
<ul>
<li>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</li>
<li>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.</li>
</ul> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=100842018-06-26T08:51:05Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=101072018-06-27T15:22:58Zdexter
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>80</i></li></ul><p>I have now tests that cover:<br />- loopback<br />- rx-only<br />- a normal bidirectional call (two times CRCX first half open, then MDCX to make call complete)<br />- a situation where an unsolicited source sends RTP packets (MGW ignors them)</p>
<p>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.</p> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=101152018-06-28T12:17:48Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>I have now added the handover situation. The patch is now in gerrit:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9768">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9768</a> MGCP_Test: add tests to verify actual RTP flows</p> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=101172018-06-28T14:19:48Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=101502018-06-29T16:00:52Zdexter
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>100</i> to <i>90</i></li></ul><p>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.</p>
<p>See also: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9787">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9787</a> MGCP_Test: do not use constant IP addresses</p>
<p>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.</p> OsmoMGW - Feature #2703: extend mgw tests to test more actual RTP flowshttps://osmocom.org/issues/2703?journal_id=101942018-07-03T13:38:09Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>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.</p>