Hi Sipos, > Thanks for the detailed explanation, I already watched your > presentations in the past, yet I was completely unaware that the E1 > based MGW has different capabilities.
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 confirm that your recent Osmo-MGW patches indeed fixed > the EFR call, which now works as expected. 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. > I wonder if this also means > we can connect EFR calls through the external MNCC or the > sip-connector to a PBX 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. > or that is still FR only for E1 based BTSes? 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. > I have and EDGE capable MetroSite with the latest SW ever released for > them, which means full AMR support, so once you have something I can > give it a try, can provide captures, logs, whatever you need. 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. > I wonder > if a similar "hack" with AMR could work, lets say for the normal 12.2 > AMR-FR calls (without fallback and other perks). 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~
