Hi Mychaela,
On Sat, Mar 25, 2023 at 01:10:13PM -0800, Mychaela Falconia wrote:
I am particularly interested in seeing a nanoBTS-generated RTP stream in either FR1 or EFR codec, as opposed to AMR or HR, coming from a GSM call UL with DTX enabled - having a 'dtx uplink' line in OsmoBSC config under 'bts N' should do it.
Please see the pcap files in https://people.osmocom.org/laforge/pcap/
specifically https://people.osmocom.org/laforge/pcap/osmobsc-nanobts-efr-dtx.pcap contains the full Abis + A + MGCP signaling (and GSMTAP logging) of a mobile-to-mobile call with GSM EFR codec using two (Calypso) MS talking to each other with DTXu enabled.
The reason for my interest? I am looking to see what the pre-existing (before Osmocom) implementation of GSM-UL-to-RTP conversion in nanoBTS does in the two corner cases of (1) the MS exercising DTX during speech pauses and (2) speech frame 20 ms windows on TCH UL being stolen for FACCH. In case 1, does nanoBTS produce an intentional gap in its transmitted RTP stream (no packets sent at all) like OsmoBTS does, or does it do something different? Does it perhaps send RTP packets with zero-length payload, or some in-band bit pattern that is meant to indicate "bad frame, no data"?
whereas stock (without my hacky patches) osmo-bts-sysmo exhibits an outright bug whereby nothing is emitted on RTP during the FACCH-stolen 20 ms window, and that gap in the RTP stream is NOT accounted for in the timestamps of subsequent RTP packets.
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.
I am not able to test this nanoBTS behaviour myself because even though I have nanoBTS hw (one PCS1900 unit and one GSM850), I have had no success in getting it to work with Osmocom - and my troubleshooting attempts hit a brick wall when the misbehaviour appears to be somewhere in the proprietary black box of nanoBTS.
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.
There was one bug in osmo-bsc I had addressed in https://osmocom.org/issues/5959
pcap file. During that test voice call, it would be ideal if the tester could alternate between speaking and silence, and also cause some FACCH activity, perhaps by pressing DTMF keys.
I didn't have the FACCH/DTMF part in the capture above, will record another one with that, plus also repeat it for (at least) FR, EFR and AMR.