mgw_fsm: Assume IuUP HNB IP addr = Iuh during MGCP CRCX on RAN side

In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for Iuh signalling.

When receiving a RAB-Ass-Req from CN, osmo-hnbgw creates an endpoint in
its co-located MGW and creates 2 MGCP conns on it, one facing the RAN
side and one facing the CN side. At that point, the remote CN IuUP IP address
is known (was include din the received RAB-Ass-Req), but the RAN one is
not yet known. Hence, the CRCX on the RAN-side conn contained no remote
IP address, which means MGW has to blindly guess a good local IP address
if "ip probing" is enabled.
As a result, when RAB-Ass-Resp comes back from the hNodeB containing the
allocated remote IuUP IP address and MGW is updated through MGCP MDCX,
it may happen that MGW rebinds to a better fitting local IP address and
returns it in MDCX. This has several downfalls:
1- We don't yet support updating the hNodeB about the changed IP address
(see mgw_fsm_mdcx_hnb). For that, we'd need to send a RAB-Modify-Req+Resp.
2- Even if we supported it, in the general case we'd be delaying call
establishment because an extra roundtrip is needed to update
RAB-Modify-Req+Resp.

In general, the HNBs end up binding its IuUP/RTP streams to the same IP
address used for the Iuh signalling. Hence, use this assumption to
announce the Iuh IP address as a remote IuUP IP address when
transmitting the MGCP CRCX at the RAN-side conn to the MGW. This way
the MGW can potentially select a proper local IuUP IP address from the
start, so no RAB-Modify-Req is required later on.

The logic to transmit RAB-Modify-Req is left unimplemented in this
commit and is left as a later improvement.

Related: SYS#6657
Change-Id: Icf43e3a1cde809d844f17ef2d0600efe64bc3dfe
---
M src/osmo-hnbgw/mgw_fsm.c
1 file changed, 56 insertions(+), 0 deletions(-)