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 _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
