Cellular Network Infrastructure » OsmoMGW

I've been doing some MGW work, I'll try to bisect the cause.

dd1ddf74fcfce3ef6fc276c72d4d18b877512c0a is the first bad commit
commit dd1ddf74fcfce3ef6fc276c72d4d18b877512c0a
Author: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Date:   Fri Dec 1 01:52:43 2023 +0100

check_rtp_origin: drop special case for legacy IuUP hack

We have proper IuUP support and everything about this legacy hack should
be purged.

The purpose of this function is to validate that RTP is coming from the
expected address and port. To allow that legacy IuUP hack, which is no
longer needed, we punched a hole into this validation, by adding this
special case for loopback mode (suddenly we don't care who or what sends
RTP and bounce it back to anyone). So let's get rid of this hole that
was only needed for very early 3G voice hacking.

Instead, we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b

Related: SYS#6657
Change-Id: I158dd046fdfcb10392cde3de8cc88dd095a05b40

src/libosmo-mgcp/mgcp_network.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)

This test specifically tests whether osmo-mgw responds to an unknown remote address.

I think our agreement is that osmo-mgw must be told the remote RTP address and port to respond to.
This test sends a CRCX without a remote RTP address, and then runs some RTP.

• in loopback mode,
• and the remote address was not set yet

Why did it do that?
Because when I first hacked on 3G voice, I punched this very specific hole into osmo-mgw,
to accomodate a very questionable hack that happened to work for all the wrong reasons.

My conclusion here is that the test is wrong. When no remote address is set, osmo-mgw should not respond.
It's not a bug, it's a feature.
dexter pespin laforge do you agree with this conclusion, or is there something I'm missing? Thanks!

I would adjust the test to expect 0 packets. It would (accurately) fail on 'latest' then:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36466

Hi neels ,

I'd need to dig deeper into this, but it may be that still in 3G (without hacks) you need to "accept" the incoming packet (IuUP Init) so that the userplane is setup successfuly (IuuP Init ACK) before the HnodeB answers the RAB assignment and hence HNBGW sets the remote address on the MGW.

We could then discuss the details:
- Whether we really need "loopback" to work under that scenario (it's more like 3G specific forwarding of IuUP Init and answering/forwarding back IuUP Init ACK)
- Whether we really want to "accept" any packets or only IuUP INIT/INI-ACK (or whatever IuUP signalling).

I'd need to dig deeper into this, but it may be that still in 3G (without hacks) you need to "accept" the incoming packet (IuUP Init) so that the userplane is setup successfuly (IuuP Init ACK) before the HnodeB answers the RAB assignment and hence HNBGW sets the remote address on the MGW.

I dimly remember us discussing this before and that I confirmed last time that
none of this hack is needed... I did all of my recent voice codecs testing
without this old loopback hack.

The loopback aspect originated from that early hack -- you'd never have
associated IuUP Initialization with loopback otherwise, because they should not
be and are semantically not related in any way at all.

One specific pointer is that the IuUP FSM doesn't hook in that RTP loopback
code path that was removed. I see in check_rtp_origin(), we do a specific iuup
check:

if (mgcp_conn_rtp_is_iuup(conn) && !conn->iuup.configured) {
/* Allow IuUP Initialization to get through even if we don't have a remote address set yet.
[...]

I think this was all discussed in dd1ddf74fcfce3ef6fc276c72d4d18b877512c0a:
"we permit RTP for IuUP Initialization regardless of the RTP
loopback/send/recv mode since I6c365559a7bd197349f0ea99f7a13b56a4bb580b"