Feature #5975


Provide a configurable option to emit a continuous RTP stream without gaps

Added by falconia 6 months ago. Updated 6 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


Some people, such as the present developer, have a desire to interconnect their Osmocom-based GSM network to their country's PSTN, and the least expensive way to do so is to use a PSTN-via-SIP connectivity provider. At least in the USA telecom environment (the underlying PSTN itself plus various providers who enable VoIP aka SIP+RTP connection to it) the cultural expectation is that G.711 RTP streams between interconnected parties are fully continuous, with a packet carrying 160 PCM samples sent every 20 ms without fail. Achieving interconnection between a private GSM network and the public national G.711 voice network requires implementation of a transcoding RTP-based MGW, and this MGW must perform all those functions that were performed by TRAUs in the original E1-backhaul GSM architecture: not only the main path of speech transcoding, but also comfort noise generation when GSM call UL goes into DTX and error concealment when GSM call UL experiences frame loss to FACCH stealing or bad radio conditions.

Implementation of the just-described TRAU functional equivalent in the form of a transcoding RTP-based MGW, with the requirement that it emits a continuous G.711 RTP stream (160 samples every 20 ms) at all times, even when generating comfort noise or substituting for lost GSM UL frames, becomes dramatically easier and better in terms of end-to-end performance (no latency or jitter artificially added by this MGW) if the IP-based BTS that sits at the ultimate origin of the UL RTP stream can be forced to emit some RTP packet every 20 ms, be it rain or shine, as opposed to the generally accepted industry standard behavior (ip.access nanoBTS, current OsmoBTS) of producing an intentional gap in the RTP stream when there are no received-from-MS speech or SID frames to be sent.

My desire is to add a vty-configurable option to OsmoBTS that would select which of several possible behavior choices should be invoked in those time windows in which there is no good speech or SID frame to be sent, corresponding to the BFI=1 condition on a traditional E1 TRAU uplink. The default will remain the same as now (produce an intentional gap in the emitted RTP stream), but other (newly added) options will be to generate one of several possible representations of BFI in RTP.

In the case of FR1 and EFR codecs, one BFI representation option I wish to support is the one invented and implemented by Themyscira Wireless:

Other BFI representation options (for FR and EFR) that should be supported are:

  • Sending an RTP packet with a zero-length payload. There are many places throughout Osmocom code base where (rtp_payload_len == 0) means no data, and it stands to reason that some people may naturally extend the same representation to RTP.
  • Sending an RTP packet containing a normally-encoded FR or EFR frame, but with all bits of that actual FR or EFR frame set to 0. I was not able to find any standard or spec that calls for such, but osmo-bts-trx currently produces such BFI packets in some rarely-exercised corner cases.

My current focus is solely on FR1 and EFR codecs; handling of AMR and HR1 will need to be tackled separately at a later time.

Related issues

Related to OsmoBTS - Bug #5974: When TCH UL frames are stolen for FACCH, RTP stream from sysmoBTS is messed upResolvedfalconia03/27/2023

Actions #1

Updated by falconia 6 months ago

  • Related to Bug #5974: When TCH UL frames are stolen for FACCH, RTP stream from sysmoBTS is messed up added
Actions #2

Updated by falconia 6 months ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

The desired feature is implemented in these two commits in master:

My other idea of implementing a special BFI marker packet format for FR and EFR that also carries the TAF bit is withdrawn for now - I found a different way to implement the desired functionality that would work even better than my original method, and I will be preparing a new proposal later. Thus I am closing the present feature ticket as done.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)