Seeking pcap of RTP stream from nanoBTS

[Mychaela Falconia]

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