Progress with voice calls in FreeCalypso GSM fw

Mychaela Falconia falcon at ivan.Harhan.ORG
Sat Mar 19 20:16:11 CET 2016


Hello FC community,

I got a small paid consulting gig (my client is in a non-Western,
non-1st-world region where people are not so obsessed with copyright
worship and regulatory approval) to implement a certain non-standard
feature in FreeCalypso GSM firmware: rerouting the voice call traffic
channel (TCH) to an external host similarly to OsmocomBB's LCR
feature, whereby the external host will see all downlink TCH bits
after demodulation, A5/1 decryption, deinterleaving and error
correction (channel decoding) but before voice codec processing, and
the same external host will be able to send its own TCH bits (at the
same point in the chain, i.e., 260 bits every 20 ms) into the uplink,
replacing the built-in vocoder uplink output.

The code for the special feature which I'm implementing for my client
will appear in the mainline freecalypso-sw repository on Bitbucket
(the feature will need to explicitly enabled at compile time; without
the corresponding feature line in build.conf, the firmware will remain
100% unchanged and unaffected), but I will explain how it works in
more detail after I'm done implementing and testing it.

But in the process of working on this TCH rerouting special feature, I
discovered that our current support for regular voice calls is not as
badly broken as I thought it was.  Specifically, the degree of
functionality vs. breakage with respect to voice calls in our current
gcc-built gsm-fw appears to depend significantly on which codec is in
use:

* When the network selects AMR, voice calls seem to connect without
  the DSP blowing up, and it seems like the audio transmitted to the
  far end is good, but only noise is heard in the earpiece speaker
  instead of the downlink voice audio.

* When the network selects EFR, the DSP blows up with errors before
  the call even connects.  (With MO calls it blows up and terminates
  the call before the called phone even rings.)

* When the network selects the plain old FR codec, the behaviour
  appears to be hit and miss: the last time I tried it on Operator
  310260's network in October, the call connected w/o DSP errors, but
  there was no audio passing in either direction.  But I just tried it
  again last night (still with Operator 310260, but in a different
  part of California), and this time the audio was perfectly good in
  both directions on all of my test calls.  Das Signal also reported
  back in October that it worked for him on his OpenBTS test network
  that always uses the FR codec.

So it seems like until we get our L1 fixed to where it would work no
worse than our TCS211 golden reference (which works 100% with all
codecs), our safest bet is to stick with the plain FR codec.  While
the network ultimately selects which codec will be used, the MS
(mobile station) advertises to the network which codecs it supports.
With TI-based firmwares this advertising of capabilities is controlled
by the MSCAP PCM record, which can be edited by writing a /pcm/MSCAP
file into FFS with fc-fsio or by changing the compiled-in default in
pcmdata.c in the firmware source - the compiled-in setting takes
effect if there is no /pcm/MSCAP file in FFS and is overridden
otherwise.

In the light of the current situation, I just pushed a change into the
freecalypso-sw repository on Bitbucket: as a temporary hack until we
get our L1 properly fixed, the compiled-in MSCAP default in pcmdata.c
is now set to 01 00 00 00 00 00 (it's a 6-byte record), which tells
the network that we only support the FR codec.  Anyone who would like
to experiment with EFR, AMR or half-rate traffic channels can
re-enable them by patching the source for their local build or by
writing a /pcm/MSCAP file into the FFS on their test device.

Happy hacking,
Mychaela


More information about the Community mailing list