Hi Csaba,

I managed to set up my E1 based Nokia BTS, the complete Osmo-CNI stack, SIP-connector and Asterisk. MO/MT calls do work as well as external SIP calls to and from mobile as well. But no matter what I do only plain FullRate calls are possible.

What version of Osmocom CNI software are you using: 2023-02 stable release or current master? The distinction is a big one: shortly after the 2023-02 release was cut, the long-standing SDP-fication patches by Neels were merged. I haven't studied those patches in full detail yet, but the changes appear to be very massive (paradigmatic) and when I tried running current master, it was totally broken for me. I currently run my production network (interconnected to USA PSTN) with 2023-02 version of Osmocom CNI. More precisely, I run this stable version plus some small patches - see falconia/production branch in osmo-hlr and osmo-msc - but these patches don't change anything significant.

It will be a while before I have the requisite time slice to study the SDP-fication patches that have been merged into current master and find a way to repair / mitigate / work around the damage caused by them. I will also need to set up a separate test environment for playing with the new code, separate from my production network.

Under osmo-bsc.conf code support is set like this (the BTS HW do support all of these codecs): codec-support fr efr amr but once I also add "codec-list fr3 fr2 fr1" to the MSC section of the osmo-bsc.conf, the calls wont establish anymore.

In the 2023-02 version the vty option in OsmoBSC (under msc 0) is called codec-list, not codec-support, and in this good OsmoCNI version this OsmoBSC vty setting is the only config setting in the entire stack that determines not only which codecs will be used, but also the order of preference for codec selection at the time of channel assignment. Some practical possibilities:

* The default is "codec-list fr1 [...]". With fr1 listed at the head of the list, the rest doesn't matter: with FRv1 indicated as the first choice and with every GSM MS support FRv1, the selection will always be FRv1.

* If you set "codec-list fr2 fr1 [...]", the network will switch to preferring EFR. If the MS support EFR, then EFR will be chosen; if the MS does not support EFR, then the fallback is FRv1. (This is my production config.)

* If you set "codec-list fr3 fr2 fr1 [...]", you will get the standard behavior implemented by most commercial GSM networks:

- if the MS supports AMR, then AMR will be used; - if the MS supports EFR but nor AMR, then EFR will be used; - if the MS supports neither AMR nor EFR, then FRv1 will be used.

I watched Neel's OsmoDevCall presentation on this topic, but it is not very clear what codecs are supported when osmo-sip-connector and an external PBX is used?

I won't be able to help you with osmo-sip-connector or external PBX - I don't use either of those - but to test and prove that the lower-level components of OsmoCNI stack are working, you should try switching to the internal MNCC in osmo-msc and see if that config works with all codecs of interest to you.

On my production network I run OsmoMSC with external MNCC, but that external MNCC is not osmo-sip-connector - it is my own alternative implementation of the component which ETSI/3GPP specs call GMSC - gateway MSC, the gateway to the host country's PSTN. For calls from one local GSM subscriber to another, my external MNCC is an exact copy of the internal one built into osmo-msc - but for calls to and from outside PSTN, my GMSC transcodes RTP to G.711 PCMU or PCMA. Because the local MS-to-MS path in my production network is identical to OsmoMSC's internal MNCC, I have a high level of confidence in the latter, which is why I recommend it as a test path.

Keith wrote:

I'm actually not sure about the state of transcoding in the MGW, maybe somebody has WIP in a branch.

I am not aware of anyone having implemented transcoding inside osmo-mgw, but most production networks implement a transcoder in whatever element connects to the {OsmoMSC+OsmoMGW} entity. As I understand it, in the case of Rhizomatica this transcoder is an off-the-shelf piece of software operating somewhere in SIP universe; in the case of Themyscira Wireless the transcoder is a "soft TRAU" implemented by me, transcoding between FR/EFR on the GSM side and PCMU/PCMA on the PSTN side, no other combinations.

M~