Hi Sipos, You should have said right away, in your initial post, that your issue was specifically with E1 BTS, as opposed to OsmoBTS or ip.access nanoBTS. To me this part was immediately obvious from the Remote Transcoder Failure cause value (plus having seen your name previously in the context of E1 BTS), but it looks like Neels missed this key detail. In your later follow-up: Thank you for clarifying. :-) Now onwards with your actual problem: let us split it into EFR and AMR, i.e., address each of these newer-than-FRv1 codecs separately. For EFR, this patch will probably get you closer to working state: https://gerrit.osmocom.org/c/osmo-mgw/+/39477 To be absolutely clear, it is _not_ a Truly Proper fix - and furthermore, the Truly Proper fix I wish to implement (TFO transform per 3GPP TS 28.062 section C.3.2.1.1 for EFR codec) is still very far away, given the current state of my priority queue. However, it should get you closer to a working state: with the above patch, you won't be getting the Remote Transcoder Failure indication from the BTS, i.e., the BTS will be kept happy in terms of what it sees on E1 Abis downlink. It is the best we can do on a short time scale. (And yes, I spent today doing this patch series specifically because I felt prompted by your experience of running into this bug.) See trau_frame_up2down() function in libosmo-abis (very deprecated code, but still present in mainline libosmo* suite) - I never played with the old OsmoNITB (I joined Osmocom well after the split), but I reason that old TRAU code must be what the old OsmoNITB used. Needless to say, it is nowhere close to what we need in terms of a proper TFO transform. I invite you to watch the video of my most recent OsmoDevCall presentation on this topic (2025 Jan), and/or look at my posted slides from that talk. Now onwards to AMR. Here the situation is simpler: OsmoMGW-E1 does not support AMR at all. Furthermore: * The work to add AMR support for E1 BTS would need to begin in the libraries (libosmotrau in libosmo-abis.git) before tackling the application, as in OsmoMGW-E1 or a wholesale replacement; * Experimentation will be needed with specific E1 BTS (Ericsson RBS6k in my case, or Nokia MetroSite in your case) to see if the BTS can handle the behaviors of TS 26.094 section A.5.1.2.3 (accept SPEECH_BAD, SPEECH_DEGRADED, SID_BAD and NO_DATA frames in DL) _without_ involving BTS-controlled TFO-AMR. Again, please refer to my TFO presentation. HTH, M~

Hi Sipos, It is not just a matter of "E1 based MGW" having different capabilities, the whole paradigm of how the BSS works in the CS domain (voice or CSD) is different between OsmoBTS vs legacy E1 BTS. When the BTS is some form of OsmoBTS (be it sysmoBTS or SDR), the BSC-associated OsmoMGW instance should ideally be reduced to a no-alteration packet forwarder, i.e., all RTP patching functions should be disabled, and the MGW is nothing more than a dumb forwarder between two UDP IP:port sockets. OTOH, if you operate with E1 BTS, then the very essence of how speech or CSData frames are represented in transport is different between the E1-based Abis interface and the IP-based A interface (TRAU frames vs RTP), and the BSC-associated MGW becomes a highly complex network element that needs to do far more work than what is needed when merely bouncing RTP packets around from one IP:port leg to another. I am happy to hear that my band-aid fix made an improvement for you, my dear fellow hacker! As long as you remember that it is only a band-aid fix and that OsmoMGW-E1 is still absolutely not correct architecturally (for any codec), we are good... Beyond band-aid fixes, I won't be able to start using E1 BTS seriously (putting high-powered Ericsson RBS6k setups at mountaintop sites, etc) until I replace OsmoMGW-E1 with this alternative: https://gitea.osmocom.org/themwi/tw-e1abis-mgw The above project is only a WIP, nothing functional yet, but if you look at ul_path.c, dl_path.c and tfo_xfrm.c modules, you will see my principal idea for the MGW between Abis-E1 and AoIP - which is very different from how OsmoMGW-E1 does it. But when I do get around to finishing this new MGW, my vision is that it will drop in the place of OsmoMGW-E1 without needing any changes in OsmoBSC, i.e., I plan to implement the subset of MGCP required by OsmoBSC in a fully compatible manner. Several conflated issues to unpack here: * External MNCC != osmo-sip-connector! I've been running with my own ThemWi CN software interfacing to OsmoMSC via external MNCC for over 2 y now. * A PBX is not the only kind of entity one can attach to external MNCC: my ThemWi CN software is very much _not_ a PBX. * I am not aware of any non-GSM-specific, off-the-shelf software (PBX or otherwise) that implements EFR correctly. My home GSM network does run with EFR, using my own ThemWi CN software, but like I just said, it is highly custom, very GSM-specific software, not a PBX. * My ThemWi CN software won't work with OsmoMGW-E1 as the latter exists today - my CN sw will only become usable with E1 BTS when ThemWi E1 Abis MGW linked above becomes a reality. With my patches of the present thread merged, the current state of partially working (or the degree of brokenness, whichever way you look at it) in OsmoMGW-E1 is the same between FRv1 and EFR. However, if you are connecting non-GSM-specific off-the-shelf PBX software to MNCC via osmo-sip-connector, then you can get a kinda-sorta-working setup with FRv1 if you abide by a ton of restrictions (such as disabling DTXu), whereas with EFR the off-the-shelf (non-custom) software route is a no-go. Hmm, your offer does sound attractive: depending on how well this idea of across-the-world remote cooperation works out, perhaps we could test an E1 BTS with AMR without waiting for me to get my Ericsson RBS6k gear up and running. Take a look at this program: https://gitea.osmocom.org/themwi/e1-fake-trau Can you get it working in your environment with FR/EFR? My plan for experimenting with AMR on E1 BTS is to take this fake TRAU program and extend it to emit TRAU-DL frames for AMR in addition to FR/EFR - hence being able to run it at all would be a prerequisite for this avenue of experimentation. If you are asking for a quick, low-effort hack that would bring AMR support (in the world of E1 BTS and Osmocom) to the same level where FR and EFR are today, then I have to disappoint you: there isn't one. The approach I personally wish to pursue is to first migrate from osmo-mgw to tw-e1abis-mgw for the role of OsmoBSC-driven E1 Abis MGW, working with existing FR/EFR codecs (or just FRv1, in the absence of TFO transform implementation for EFR) and CSD, and only then add AMR support to it. But of course if you wish to do it yourself, or if some other developer would like to tackle AMR support with E1 BTS, and you do like mainline OsmoMGW, then I leave up to you how you wish to proceed. :) M~