Hi Harald,

Please see the pcap files in https://people.osmocom.org/laforge/pcap/

specifically https://people.osmocom.org/laforge/pcap/osmobsc-nanobts-efr-dtx.pcap

The server returns "403 Forbidden" for the linked file and for most other pcap files in that directory, including most interesting ones.

[sysmoBTS FACCH issue]

I would agree this is a bug. Irrespective of whether you have a (hacky or not) patch, it would make sense to have this in the osmo-bts bug tracker.

OK, I will write up the bug issue.

To my big surprise, my Osmocom setup worked fine with the nanoBTS i have (model 165AU, DCS1800). I'd have expected more bit-rot given that we don't know anyone regularly using such a setup anymore.

My first attempt was almost a year ago in 2022-04, using a PCS1900 unit. I posted my pcap file on the ML, you looked at it and told me that there seemed to be a problem with TA control loop. Yesterday I tried with my GSM850 unit and the behaviour appeared to be the same.

There was one bug in osmo-bsc I had addressed in https://osmocom.org/issues/5959

Does your fix make the difference between the setup working and not working? IOW, did it work prior to your WIP OS#5959 fix? If the setup worked even before that fix, then it probably won't fix whatever issue I am having here.

M~

Thank-you to Harald for capturing and publishing these files:

Please see the pcap files in https://people.osmocom.org/laforge/pcap/

Here is my analysis, focusing on FR1 and EFR codecs in osmobsc-nanobts-fr-dtx-dtmf.pcap and osmobsc-nanobts-efr-dtx.pcap - I don't feel ready to look at AMR yet.

The behaviour I see from the nanoBTS is the same as what has been implemented in mainline OsmoBTS: whenever the UL from the MS goes into DTX or whenever a 20 ms traffic frame slot has been stolen for FACCH, the BTS transmits nothing on RTP and generates an intentional gap in its outgoing RTP stream. By "intentional gap" I mean that when the next RTP packet does go out at some later time, the sequence number is incremented by 1 relative to the last packet before the gap, but the timestamp is incremented by (N+1)*160, where N is the number of 20 ms packets that were suppressed.

This finding is disappointing - I was hoping that they did something more PSTN-transcoder-friendly - but it is what it is, and thanks to Harald's experiments and pcap files, we now know the facts as to what at least one historical proprietary vendor had implemented prior to Osmocom.

Now let me share some observations about USA PSTN and its "modern" incarnation in the form of SIP+RTP. My observations are based on the service I get via bulkvs.com - it's an ultra-cheap bulk telephony service providing access in the form of VoIP/SIP to the USA+Canada portion of the global worldwide E.164 PSTN. Through this service I have reserved several fully "real" and functional E.164 numbers in the USA number space (NANP), calls from other people's phones to any of these numbers turn into SIP INVITEs going to my server, and I can likewise dial outbound calls from my gateway to any phone number in +1. They support G.711 and G.729, but I only use G.711.

The aspect of USA PSTN and its SIP+RTP form that is most relevant to the present discussion of RTP from a GSM BTS is the "shape" of G.711 PCMU RTP streams which I receive whenever I am SIP-connected to any USA phone via BulkVS. I've been playing with this service since 2022-06, I have made calls to and received calls from many kinds of different phones (GSM phones on legacy T-Mobile 2G, "modern" VoLTE phones, POTS analog land line, various "office" phones as in banks etc), and the PCMU RTP stream I receive always looks the same: perfectly smooth and continuous, a packet of 160 PCMU samples coming every 20 ms without fail, as if the stream is coming from a TDM to RTP converter.

Seeing that apparently-all phone systems connected to USA E.164 number space produce such perfectly smooth and continuous RTP streams, I conclude that my public-interfaced GSM network needs to produce outgoing RTP streams (emanating from my PSTN-via-SIP interconnection gateway) that are no worse than the others, i.e., just as smooth and continuous, sending a packet of 160 samples every 20 ms without fail, no matter what is happening on the GSM side. Whenever GSM call UL goes into DTX, it is the GSM network's responsibility to generate comfort noise toward PSTN per the rules of GSM 06.12 or 06.62, and whenever a traffic frame is stolen for FACCH or lost to bad radio conditions, it is likewise the GSM network's responsiblity to apply the rules of GSM 06.11 or 06.61 - suddenty stopping the RTP stream going to PSTN is clearly NOT the right course of action, as no other parties at least in the USA publicly-interconnected telecom environment are seen to do so. In the Olden Days it was the T1/E1 TRAU that did all these functions, emitting a perfectly continuous G.711 sample stream on its output, and in the present-day all-IP world it becomes the job of my transcoding fiefdom-boundary MGW to do the same.

And the easiest way to produce such a perfectly smooth G.711 RTP stream from a transcoding MGW is to force the BTS (the ultimate RTP stream timing origin) to emit *some* RTP packet in every 20 ms window, be it rain or shine, i.e., indicate what classic GSM specs call BFI conditions (times when you would see BFI=1 in UL TRAU frames) by way of some special "error" or BFI packet, rather than by complete absence of RTP packet transmission as is done in nanoBTS and current mainline OsmoBTS.

I have raised this issue previously:

https://osmocom.org/issues/5742

Now the new info we have is that the behaviour of intentional gaps in the RTP stream (the part which I consider to be a bad design) is not an original Osmocom invention, but was already present in OsmoBTS' and sysmoBTS' direct predecessor nanoBTS. For everyone reading my rants - please understand that I am *NOT* bashing Osmocom here! The only "thing" which I am "bashing" is the de facto, seemingly unwritten set of industry "standards" for IP-based GSM RAN, which in my opinion are an utter mess compared to the marvel of beauty that is traditional GSM RAN based on channelized T1/E1 lines, TRAU frames and perfect TDM timing.

Anyway, moving from rants to constructive ideas, I am going to start working on a patch to OsmoBTS that will add a vty config option to select the behaviour of what it should do when a BFI condition occurs. The default will of course be to keep the current behaviour of generating an intentional gap in the RTP stream, but I see the following options as other reasonable alternatives (for FR/EFR):

1) Emit an RTP packet with a zero-length payload;

2) Emit an RTP packet containing an FR/EFR frame of all 0 bits - that's what osmo-bts-trx does currently in the corner case of the BFI condition being for some reason other than DTXu, but the codec being EFR (no ECU) or the FR1 ECU failing;

3) Emit the ad hoc FR/EFR BFI RTP packet format which I invented for Themyscira Wireless, hereby called Themyscira FR/EFR BFI packets.

I anticipate that option 3 will likely raise the most objection from the established Osmocom community - but please let me point out that my themwi-mgw code (that receives and intelligently acts upon these Themyscira BFI packets) is public domain (see the newly added LICENSE file), free for the FOSS community to copy and modify and reintegrate in all kinds of ways, and I am not aware of anyone else having implemented a published-source transcoding MGW that is specifically designed to work with Osmocom GSM networks, connecting them to PSTN. And if the grand vision of Osmocom includes having transcoding functionality in OsmoMGW, then I'll make the argument that copying the logic from themwi-mgw would provide a solid start. I would also be more than happy to do an OsmoDevCall presentation covering ThemWi system sw, perhaps with a special focus on themwi-mgw if that is the part of most interest to Osmocom community, and explain how it interfaces with existing Osmocom CNI, why I made each design decision the way I did, and how it could potentially be brought within Osmocom CNI.

With devotion to GSM Forever, (Hasta la Victoria, Siempre,) Mother Mychaela