Hi all,
I'd like to draw attention again to the state of codecs handling in OsmoMSC master. The reason being that the recent IuUP changes create conflicts with the neels/mncc_codecs3 branch.
I fear that we are currently doing the same thing that we discourage everyone else from doing: keeping an important branch on the side and not upstreaming it. There is recurrent overhead on rebasing the branch.
Facts about OsmoMSC: master neels/codecs_mncc*
heeds MS Bearer Cap from ComplL3 NO YES logically combines codec constraints NO YES communicates available codecs to/via SIP NO YES worked at last congress NO YES has the last IuUP patches YES NO
I think the reasoning for completing that codecs work and merging the branch is compelling. Can we somehow achieve that before OsmoMSC diverges further?
I could start maybe by holding a talk on it in an OsmoDevCall? That way I've read all of the code again and can explain what the patch does why, to ease review. Or maybe spend that time on merging the code instead? Or both? :)
~N
Hi Neels,
On Tue, Jan 11, 2022 at 06:58:33PM +0100, Neels Hofmeyr wrote:
I fear that we are currently doing the same thing that we discourage everyone else from doing: keeping an important branch on the side and not upstreaming it. There is recurrent overhead on rebasing the branch.
I'm sorry it is that way, but the fact is that we have a large number of projects with ever-growing scope while the amount of contributors and developer resources (both inside and outside of sysmocom) is getting lower.
I think the reasoning for completing that codecs work and merging the branch is compelling. Can we somehow achieve that before OsmoMSC diverges further?
I think the main problem is that there is no automatic testing for the voice bearer / user plane, so we will not catch any regressions if merging a larger patchset/branch unless at least one, better multiple people sit down and manually test through the many permutations/situations of codec configurations and check if the audio works.
I could start maybe by holding a talk on it in an OsmoDevCall?
As readers of this list will have noticed, that OsmoDevCall has now been announced for this Friday. Looking forward to it!
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
-
Harald Welte -
Neels Hofmeyr -
Pau Espin Pedrol