In my previous job at Sifira A/S, I developed the first version of chan_ss7.
Chan_ss7 is a module for Asterisk, which interfaces Asterisk to an SS7 network.
So what is SS7? It is the network that runs the worlds telephone network. Chances are that as soon as your phone call reaches the local central (analog/ISDN) or base station (cell phone), it is transported over SS7. SS7 is the domain of big telephone switches from Nokia, Ericsson, and others, and a lot of very expensive and proprietary equipment.
So how does that fit with the world of cheap IP-based telephony and Free software? As it turns out, not bad at all!
Since my announcement half a year ago, a small but determined community has been slowly but steadily growing around chan_ss7. People are interfacing Asterisk to all kinds of different SS7 equipment with chan_ss7, reporting problems, discussing them, and trying to fix them. And patches are slowly starting to be contributed, though it is a bit too early to expect anything major yet. In short, just as any Free Software project should work! Anders Baekgaard and Jacob Tinning at Sifira A/S have also done a great job at taking over at Sifira and leading the development effort.
A good indication of what is going on is the asterisk-ss7 mailing list. Traffic on that list has really surged since discussions on chan_ss7 started in March. The world of SS7 is generally not very accessible and only really known by a small number of specialists in the field, so it will be very interesting to watch in the coming years how it will develop. So far, I am quite pleased with how it is proceeding.
Chan_ss7 is still in early development and somewhat incomplete, but there is some very nice code in there. The SS7 protocol has strict timing dependencies (millisecond-range), and failure to respond in a timely manner will lead to packet loss and eventually loss of service. This is why SS7 equipment is traditionally made with dedicated signal processing hardware in the network interfaces, making it very expensive.
But chan_ss7 handles SS7 in userspace, carefully architectured to meet the requirements of the protocol. The operation is split between normal Asterisk threads and a special MTP thread that runs at a high, real-time priority (using Linux’ real-time capabilities). This ensures that the MTP thread, which handles all the timing-critical parts of the SS7 protocol, will be scheduled immediately when the network device is ready, pre-empting any other user-space activity that may be going on (and with a recent 2.6 kernel with preemptiveness enabled, it can even pre-empt kernel activities).
Further care is needed in the communication between the Asterisk threads and the MTP thread. Traditional locking-based inter-thread synchronisation suffers from the problem of priority inversion: If the MTP thread waits for a lock that is held by an Asterisk thread, and another low-priority user-space process pre-empts the Asterisk thread, the MTP thread will have to wait for the low-priority process to yield the CPU, causing possible loss of service due to missed timing constraints. In effect, the priorities of the high-priority MTP thread and the low-priority process have been inverted.
Instead, the MTP thread uses a couple of lock-free FIFIO’s to communicate with the Asterisk threads. A lock-free FIFO is a message queue that allows one thread to write messages into the queue simultaneously with another thread reading messages from the queue, without risk of race conditions or the need for synchronisation. Special care is needed to work with modern SMP hardware (which optimizes memory access by reordering reads and writes), but the result is reliable and timing-compliant operation.
The non-timing critical processing is done with traditional locking in the Asterisk threads, interfacing to the Asterisk channel API. That API is actually very nicely designed, and chan_ss7 fits in very well to the Asterisk architecture. It is certainly much better than other proprietary APIs such as the ones used by Dialogic telephony hardware.