Cellular Network Infrastructure

AFAICT this relates to the codecs improvements that were added to OsmoMSC in 2023-03. With patches around https://gerrit.osmocom.org/c/osmo-msc/+/30126, it seems OsmoMSC should now be able to send multiple codecs in the CRCX towards the MGW. From the pcap, packet 1 (MGCP CRCX):

Codecs (a): GSM-EFR;GSM

Looking at the pcap in particular, something definitely looks amiss, beginning with the second captured packet where the SDP response from MGW throws the two codecs together into a single invalid rtpmap line - but I don't know enough about this protocol to tell if the bug is on OsmoMSC or OsmoMGW side.

Packet 2 (MGCP OK):

Media Attribute (a): rtpmap:96 GSM-EFR;GSM

Looks like OsmoMGW isn't parsing the CRCX correctly and generates this invalid OK.

neels, dexter: can you take a look, is the support for multiple codecs incomplete in OsmoMGW?

From log-frag2.txt:

Jun 25 19:15:22 sentinel OsmoMSC: <0024> mgcp_client.c:130 ptmap contains illegal mapping: codec=4294967295 maps to pt=96

It seems OsmoMSC passes "GSM-EFR;GSM" to map_str_to_codec() in libosmo-mgcp-client (from osmo-mgw.git) and doesn't check its return code, leading to this error message later on:

https://gerrit.osmocom.org/c/osmo-mgw/+/33527

Hi,

the below kind of prose is not a good way to report a bug.
Please stick to the actual facts relevant to the bug and reproduction recipes.
It's good to give context, but either keep that short, or put it at the end.

The rationale here is to allow a reader to quickly understand the issue.
It is super annoying to have to filter out noise when you are time pressed.

Deliberate noise is not only rude, particularly in the issue tracker it is unacceptable.

Thanks for being helpful in that regard!

falconia wrote:

Let me preface this report by saying that it is certainly not up to the quality standard for proper bug reports, and as a developer I am expected to do better. However, in my defense I have to point out that I have only one working BTS, and when I reached the limit of how much downtime I could allow on my production network, I had to abort the investigation and go back to a stable build.

ah what a coincidence, i just reported #6080 about that 'ptmap contains illegal mapping: codec=4294967295 maps to pt=96'.
Oh and I missed that we already merged a fix for it.

I am also currently busy trying to get a voice call to work with the current master versions,
on 3G hardware other than what I used when implementing the codec patches.
I'm battling with the modems, but should have some feedback on that soon...

I can reproduce the problem:

20230629220457698 DLMGCP ERROR Failed to parse SDP parameter, can't parse codec in rtpmap: "a=rtpmap:96 AMR;AMR-WB" (mgcp_client.c:397)
20230629220457698 DLMGCP ERROR MGCP_CONN(RTP_TO_CN)[0x559e944dde10]{ST_CRCX_RESP}: MGW/CRCX: Cannot parse CRCX response (mgcp_client_fsm.c:291)
20230629220457698 DLMGCP ERROR MGW(mgw) Empty endpoint name, can not generate MGCP message (mgcp_client.c:1444)                                

It is basically that libosmo-mgcp-client flies off the hinge when there is more than one codec in the MGCP header like "AMR;AMR-WB" -- in the header, not the SDP part. The codecs in the header are pretty insignificant, because we rely on the codecs being set up by the SDP part.

A workaround for you, falconia could be to configure osmo-msc.cfg and/or osmo-bsc.cfg to exclude one of the two codecs you are seeing. In your pcap I see "a: GSM-EFR;GSM". So now, if you forbid GSM-EFR aka FR2, chances are that the codec filter leaves only GSM, hence libosmo-mgcp-client can parse the string.

The problem is that our osmo-mgw code simply cannot parse multiple codecs as specified in RFC2705 in the "L: a:xx" header:

" * The preferred type of compression algorithm, encoded as the
keyword "a", followed by a colon and a character string. If the
Call Agent specifies a list of values, these values will be
separated by a semicolon.
"

It expects a single string and treats "GSM-EFR;GSM" or in my case "AMR;AMR-WB" as a single codec that it does not know.

I'm still figuring out whether we should

• not list more than one codec there anyway, because what possibly is the use of that.
  All important codecs bits are done via SDP.

• And/Or whether libosmo-mgcp-client should ignore anything past the first codec.

• Or whether libosmo-mgcp-client should correctly parse them, put them in the ptmap, and then let that be overwritten by SDP.

It's a bit more intricate than I thought, and it's an osmo-mgw bug.
I filed #6081 for it.

neels wrote in #note-7:

A workaround for you, falconia could be to configure osmo-msc.cfg and/or osmo-bsc.cfg to exclude one of the two codecs you are seeing. In your pcap I see "a: GSM-EFR;GSM". So now, if you forbid GSM-EFR aka FR2, chances are that the codec filter leaves only GSM, hence libosmo-mgcp-client can parse the string.

This workaround could potentially work for a functionally-limited test network (which is currently a moot point as I have yet to acquire the necessary second BTS), but I won't be able to migrate ThemWi prod network to a post-SDP-merge OsmoCNI version until all bugs (which I won't discover until I do get that second BTS, build that separate test network, and do a ton of testing) are fixed properly. On the prod network supporting both FRv1 and EFR is an absolute must: those phones that support EFR need to be connected in EFR for better voice quality, but super-old phones that support only FRv1 must also be supported by the network.

I see that you got the actual bug isolated in #6081 and already got a fix in review, so it will likely be fixed before I acquire the needed hw to proceed further on my end.

I see that you got the actual bug isolated in #6081 and already got a fix in review, so it will likely be fixed before I acquire the needed hw to proceed further on my end.

Agreed =)