As some people asked questions about my experiments with the new CSD support in the Osmocom GSM stack, I just wanted to report what I did and learned along the way.
Disclaimer: I’m just a hobbyist, fiddling around with Osmocom GSM for fun and giggles, I don’t really know what I’m doing here, so take what I’m saying with a grain of salt and maybe enjoy the pretty pictures 
“ISDN” data calls
I was pretty much immediately able to get a working CSD call (9600bps, non-transparent, AT+CBST=71,0,1) between a modern-ish Nokia 6300i and an old 6310i:
(showing incoming PPP frames, easily spottable by the many “~”-characters, which are 0x7E and used as the flag-octet in PPP’s HDLC-style framing)
“Analog” data calls
However, “analog” data calling wasn’t working at all:
In the internet connection setting dialog of Nokia phones, you can select whether the network should try to convert the CSD call into an analog modem (V.32, etc.) call or if it should try to convert it to a regular ISDN B channel protocol.
Other devices like a Nokia Communicator 9110 were tested (because those feature a nice terminal emulation feature, right on the device), but they only supported signalling the analog modem interworking. There is no way to get these very old devices to try and signal an “ISDN” CSD call.
3 small code changes were implemented (in osmo-msc and libosmocore) to get “3.1kHz audio” (aka analog modem) and Fax calls signalled properly. Some Nokia devices were still misbehaving when receiving these calls, presumably due to questionable signalling, which was workarounded with another osmo-msc change.
After that, devices like the Nokia Communicator 9110 could get some connectivity again after many years:
(terminal emulator, showing PPP traffic once again)
Time to test the HTML-capable webbrowser, running on the AMD 486 CPU in this handheld device:
Neat, works like a charm!
Other, WAP over CSD capable devices were now also able to connect to the internet.
(sidenote: This particular device does support GPRS already, but was still a useful test subject)
Modern devices support
@fixeria then noticed a discrepancy in the Bearer Capability encoding between incoming/outgoing calls. This was again fixed in libosmocore, which led to working incoming calls on all tested devices (
):
This also fixed all the issues with Huawei and ZTE 3G/UMTS USB dongles and CSD.
Terminating data calls in software
I then went ahead and wrote a proof-of-concept decoder for V.110 RLP frames in SIP/RTP data:
You can see the FSI/frame sequence index increasing, 4 V.110 packets (with 60 bits of data) combine to make a 240 bit, 30 byte RLP frame:
To my great surprise, the phones are actually happy with a plain loopback. When repeating every bit of the V.110 stream back to them 1:1, they’ll establish a connection with themselves. This is super useful when trying to implement a decoder, as you get real-life test data fed directly into your software
@laforge thankfully already wrote a RLP dissector implementation a couple of months ago and submitted it to wireshark.
He also added support for the V.110 sync patterns to libosmo-abis last year.
My GSM network setup includes osmo-sip-connector and a Yate PBX, which can route calls to executable calls (and then exchange PCM samples and control messages via file descriptors):
I spent some hours debugging this trying to notice what was wrong, until I noticed that I misread the GSM 08.20 spec, which referred to D1 through D48 bits and then D’1 through D’12 bits.
I mistakenly decoded those as D1-D48, D’1-D’12 at first, when they were in-fact pretty much ordered in incoming bit order (“left to right and top to bottom”, to quote the spec). Whoops!
RLP now needs to be implemented here. To be continued 
Fax
Fax over CSD is transported as a 9600bps transparent CSD call.
There is still V.110 framing involved, but no RLP.
3GPP TS 43.045 specifies a small protocol to handle synchronisation on the bitstream and also signalling/status reporting for interworking with an analog modem (of a real fax machine on a landline/POTS interconnect). After that, the data is bit-compatible with the T.30 implementations of any regular G3 fax machine.
From my collection, only the Nokia Communicator 9110 and my Nokia 6310i have support for GSM faxing. The newer devices (6230i and above) don’t support this anymore, sadly.
@laforge mentioned that he had previously had success using a free/open software fax called “efax”.
After installing a modern version of Debian Linux on a laptop with an IrDA transceiver, patching the userspace IrDA tools and debugging & fixing the kernel space IrDA drivers (which someone has thankfully maintained as an out-of-tree module for modern kernels) for a T43, I was able to establish an IrCOMM serial link to the 6310i from Linux:
Connection setup between devices didn’t work at first, though. The incoming leg of the call was being signalled as “Facsimile group 3”, but the outgoing leg was signalled as “Unrestricted digital information”.
I hacked/ugly-patched support for this into osmo-msc and was then able to establish my first ever (haven’t even done this in commercial networks) GSM fax connection and send my first GSM fax ever (from the Nokia Communicator 9110 to efax on Linux):
Sending from efax to the Communicator did work as well:
root@t43-debian ~ # efax -d /dev/ircomm0 -o f -o 2.0 -t 5006 outgoing2.tiff
efax: Mon Oct 16 22:35:09 2023 efax v 0.9a-001114 Copyright 1999 Ed Casas
efax: Mon Oct 16 22:35:09 2023 efax v 0.9a-001114 Copyright 1999 Ed Casas
efax: 35:09 compiled May 12 2022 04:16:23
efax: 35:09 Warning: unrecognized protocol option (.)
efax: 35:09 Warning: missing TIFF compression format, set to raw
efax: 35:09 opened /dev/ircomm0
efax: 35:11 using Nokia 6310i Nokia Nokia 6310i V 7.00 in class 2.0
efax: 35:12 dialing 5006
efax: 35:22 connected
efax: 35:30 session 196lpi 9600bps 8.5"/215mm any 1D - - 0ms
efax: 35:30 header:[Mo 16 Okt 2023 22:35:09 CEST P. 1]
efax: 35:59 sent 20+1112 lines, 26048+0 bytes, 29 s 7185 bps
efax: 35:59 sent -> outgoing2.tiff
efax: 35:59 done, returning 0 (success)
That’s the T43, connected to the 6310i via IrDA – Looks good!
Terminating fax calls in software
I then went ahead and tried to decode the (packed captured) RTP bitstream with C software.
I was able to interface with libspandsp and it’s T.30 implementation to get this beautiful .tiff file out of the RTP mess (I.460, V.110, FA):
(yes, this looks the same, because it’s exactly the same fax, just got it in a very, very different way).
The current code is worse than a proof-of-concept (seriously, it was 4:00 AM and you might go blind reading it) and will immediately break with any strange input, but I still learned a lot about fax and T.30.
To be continued (again), this needs a FA encoder and a proper implementation of the sync pattern as well as the state machine.
We could then probably either queue or directly connect GSM and analog fax machines through Yate. 