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. -- - Harald Welte <[email protected]> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
