Chapter 0: Problem Statement
In an all-IP GSM network, where we use Abis, A and other interfaces
within the cellular network over IP transport, the audio of voice calls
is transported inside RTP frames. The codec payload in those RTP frames
is the actual codec frame of the respective cellular voice codec. In
GSM, there are four relevant codecs: FR, HR, EFR and AMR.
Every so often during the (meanwhile many years of ) development of
Osmocom cellular infrastructure software it would have been useful to be
able to quickly play back the audio for analysis of given issues.
However, until now we didn't have that capability. The reason is
relatively simple: In Osmocom, we genally don't do transcoding but
simply pass the voice codec frames from left to right. They're only
transcoded inside the phones or inside some external media gateway (in
case of larger networks).
Chapter 1: GSM Audio Pocket Knife
Back in 2010, when we were very actively working on OsmocomBB, the
telephone-side GSM protocol stack implementation, Sylvain Munaut wrote
the ,
which was sufficient for my debugging needs back then. Still, you had
to save the decoded PCM output to a file and play that back, or use a
pipe into aplay.
Last week, I picked up this subject again and added a long series of
patches to gapk:
support for variable-length codec frames (required for AMR support)
support for AMR codec encode/decode using libopencore-amrnb
support of all known RTP payload formats for all four codecs
support for direct live playback to a sound card via ALSA
All of the above can now be combined to make GAPK bind to a specified
UDP port and play back the RTP codec frames that anyone sends to that
port using a command like this:
$ gapk -I 0.0.0.0/30000 -f rtp-amr -A default -g rawpcm-s16le
I've also merged a chance to OsmoBSC/OsmoNITB which allows the
administrator to re-direct the voice of any active voice channel towards
a user-specified IP address and port. Using that you can simply
disconnect the voice stream from its normal destination and play
back the audio via your sound card.
Chapter 2: Bugs in OsmoBTS GSM-HR
While going through the exercise of implementing the above extension to
gapk, I had lots of trouble to get it to work for GSM-HR.
After some more digging, it seems there are two conflicting
specification on how to format the RTP payload for half-rate GSM:
from 2010
In Osmocom, we claim to implement RFC5993, but it turned out that (at
least) osmo-bts-sysmo (for sysmoBTS) was actually implementing the
ETSI format instead.
And even worse, osmo-bts-sysmo gets event the ETSI format wrong. Each
of the codec parameters (which are unaligned bit-fields) are in the
wrong bit-endianness :(
Both the above were coincidentially also discovered by Sylvain Munaut
during operating of the 32C3 GSM network in December 2015 and resulted
the two following "work around" patches:
*
Those merely worked around those issues in the rtp_proxy of OsmoNITB,
rather than addressing the real issue. That's ok, they were "quick"
hacks to get something working at all during a four-day conference. I'm
now working on "real" fixes in osmo-bts-sysmo. The devil is of course
in the details, when people upgrade one BTS but not the other and want
to inter-operate, ...
It yet remains to be investigated how osmo-bts-trx and other osmo-bts
ports behave in this regard.
Chapter 3: Conclusions
Most definitely it is once again a very clear sign that more testing is
required. It's tricky to see even wih osmo-gsm-tester, as GSM-HR
works between two phones or even two instances of osmo-bts-sysmo, as
both sides of the implementation have the same (wrong) understanding of
the spec.
Given that we can only catch this kind of bug together with the hardware
(the DSP runs the PHY code), pure unit tests wouldn't catch it. And the
end-to-end test is also not very well suited to it. It seems to call
for something in betewen. Something like an A-bis interface level test.
We need more (automatic) testing. I cannot say that often enough. The
big challenge is how to convince contributors and customers that they
should invest their time and money there, rather than
yet-another (not automatically tested) feature?
SOCIAL SHARE CARD GENERATOR