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