Seeking pcap of RTP stream from nanoBTS

[Mychaela Falconia]

Hello GSM community,

Would anyone in either of the two sub-communities of GSM (OsmoCNI and
FC) happen to have a working setup with an ip.access nanoBTS,
specifically with working voice calls?  For the purpose of this
inquiry, that "working setup" can be either with Osmocom CNI sw or
with whatever original proprietary sw was once "official" for these
ip.access nanoBTS units.  If anyone does have a working nanoBTS setup
with any sw, would you be willing to produce and share a packet
capture (pcap file) of a working voice call, particularly the RTP
stream originating from the nanoBTS?  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.

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"?  Case 2 is also interesting: current
osmo-bts-trx (based on my reading of code, no hw to test on) invokes
FR1 ECU and emits its output in this case, 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.  Once again, I can only wonder what the pre-Osmocom
implementation in nanoBTS does in this case.

I would really like to produce a clean, potentially-mergeable patch to
OsmoBTS and submit it to Gerrit, a patch that would add vty config
settings selecting among several possible behaviours for RTP output in
cases of DTX silence, FACCH stealing or bad radio Rx - but I really
need to know what the different "reasonable" behaviour choices are,
and I feel that we as in FOSS GSM community also need to know what our
proprietary predecessors did in this area.

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.  Hence I really need help from
someone in the community who does have a working nanoBTS setup (with
any sw) and who could make some test voice calls (ideally one FR1 and
one EFR, but even just one of these two codecs would be interesting to
see) with an RTP packet capture running, and then share the resulting
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.

M~