Hi,
sharing a few thoughts for the osmodevcall tomorow.
I did a few tests today with a 2G and a 3G network, using current master of everything plus:
* my osmo-mgw IuUP patch for osmo-mgw: https://gerrit.osmocom.org/c/osmo-mgw/+/26823
* Philipp's osmo-hnbgw.git branch pmaier/mgw which makes osmo-hnbgw use osmo-mgw to route calls
2G_MO <-> 2G_MT: Fine, as usual.
3G_MO <-> 3G_MT: Everything seems to be working fine here. MSC and HNBGW configure all MGCP conns during CRCX with IuUP (audio codec "VND.3GPP.IUFP/16000"). When receiving that audio codec, osmo-mgw upgrades the conn to be of type "IuUP" and handles packets/state accordingly. Then IuUP is used everywhere and properly routed nano3g <-> MGW_hnbgw <-> MGW_msc <-> MGW_msc <-> MGW_hnbgw <-> nano3g. IuUP SMpSDU Init (ACK) are negotiated between each peer.
2G <-> 3G: The idea here is to have at least limited interoperability (no transcoding, meaning 2g network needs to probably be configured to allow only AMR, and only AMR modes supported by nano3g). osmo-mgw already takes care of reframing the AMR payload between IuUP and RTP AMR-OA/BE.
To accomplish that, lots of stuff is working fine already (see test https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26860 passing). The only main problem right now is that the CN-side endpoint connections of osmo-mgw attached to osmo-msc are not properly configured (all others look fine). Right now, osmo-msc, when sees the call leg it is preparing is for a UMTS subscription, as explained later, sends audio codec "VND.3GPP.IUFP/16000" during CRCX on both conns in the endpoint (RNC-side and CN-side). On the other leg (2G), MSC does the same but using AMR audio codec. When both legs are ready, it connects the 2 CN-side connections of each leg (2g and 3g ones) together, in call_leg_local_bridge(), using MDCX on both, and it actually properly sets AMR codec on both, since in this case we want the 2 leg bridge between 2G and 3G endpoints to be done in RTP+AMR.
However, osmo-mgw doesn't support "downgrading" an already "upgraded" RTP->IuUP conn back IuUP->RTP during MDCX, which means MGW currently fails to process the packets because it expects to receive the other RTP vs IuUP type. And it think it shouldn't support that. Instead, we should [A] avoid probably avoid configuring any codec during CRCX on CN-side connection, to avoid the upgrade RTP->IuUP of the connection. [B] Later, during call_leg_local_bridge() when we know the codec for both, iif both conns are from UMTS subscribers then send the codec "VND.3GPP.IUFP/16000". [C] somo-mgw will then upgrade the conns RTP->IuUP during MDCX.
[A] To implement this, it's probably a one line. See osmo-msc.git d7955315646b9ba2942e4d5ae58c5d43763d9be6, we need to set .codec_present=false there. [B] This may already be done automatically. Otherwise we need to poke around call_leg_local_bridge() code to do it. [C] In my osmo-mgw patch, so far the RTP->IuUP upgrade is only done during CRCX, but it should be easy to apply the upgrade during MDCX too.
I'm attaching a sample pcap file showing a call 2g<->3G of the tests I did today. Filters used to export the file: "sctp || rtp || rtcp|| mgcp || gsm_abis_rsl"
Diagram of the IuUP/RTP paths in the pcap:
------------------ [nano3g] 192.168.1.138:1036 ------------------ || || (IuUP) || ------------------ 192.168.1.140:4002 [MGW_hnbgw] 192.168.1.140:4004 ------------------ || || (IuUP) || ------------------ 127.0.0.2:9022 [MGW_msc, 3g leg] 127.0.0.2:9024 ------------------ || || (RTP/AMR both dirs desired, currently: 1 dir RTP/AMR, 1 dir IUUP) || ------------------ 127.0.0.2:9028 [MGW_msc, 2g leg] 127.0.0.2:9026 ------------------ || || (RTP/AMR) || ------------------ 192.168.30.1:4030 [MGW_bsc] 192.168.30.1:4028 ------------------ || || (RTP/AMR) || ------------------ 192.168.30.1:16392 [BTS] ------------------
Kind regards, Pau