Sunday, February 24, 2013

ss7box Will Not Be Open Source

It's final.  ss7box will not be released to open source. There are objections.

The world is filled with telephone systems that interconnect using SS7.  They could sit there for decades just humming along.  But the 4-wire telephone interface is becoming irrelevant because wireless and IP  alternatives.  Eventually the power bill for running those systems might exceed the profit they generate.  Will there be a time when 4-wire POTS service will be discontinued?  I read that POTS service decline in the US is steady and precipitous, but it's a cash generating system that requires little input. If this is true then the incentive is to do nothing and harvest as much cash as possible while building up wireless and broadband.

The crystal ball is murky. Some things point to a slow decline and others to a faster one. It's not clear that another open source SS7 stack is needed either.  The current SS7 service providers and equipment providers will be in a race to the bottom as they face lower demand for their products and services unless they form a cartel and agree to keep prices high in order to glean as much cash from the market as possible. A couple of players, Nortel and Lucent aren't even playing anymore. Assuming no cartel will be formed, the open source SS7 stacks will fair poorly against the time-testing commercial solutions that keep getting cheaper and cheaper.

All of this adds up to a dismal outlook for open source SS7. The first working version of ss7box took me a year of full-time effort to produce.  There were people cheering me on. It was exciting.  The prospect of doing it again does not energize me.  But, if I were to do it, I'd do it differently.  The MTP2 in ss7box follows the ITU specs to the letter. Those specs are perfect.  I'd follow the specs again.  But this time I'd write it to use a bitstream from any card. Each card would require an interlock code to connect its device driver to the south end of the MTP2.  MTP2 would reside in kernel space unless RT Linux would allow it to run in top priority in user space. The downside is that E1/T1 cards are not typically RT Linux ready. I'd make the ss7 device run in a completely separate box and run under RT Linux if possible.  I'd try hard to make it compatible with box virtulizers like VirtualBox. For the MTP2 to upper layer interface, I'd make it a socket based interface.  I'd do a better job of providing for link failover-failback. The interface would have plug-in capability to convert between MTP, SIGTRAN, SIP, etc. The  message router would be re-used code from some other open source project rather than re-invented.  The ISUP encoder/decoders would be taken from Wireshark.  The configuration system would be taken from Asterisk.  The concept of circuit groups would be established at the very beginning of the project - instead of starting with circuits and then tweaking into circuit groups.  The concept of clustering ISUP and SCCP nodes around router and link boxes would be built in on the front end.  Instead of ss7box, I'd have linkbox, routebox, callbox, and servicebox that are interconnected using SCTP sockets. I'd write linkbox in C.  I'd write the other boxes in Java.

By the time this project is ready, the demand for SS7 will have declined even more. I'd be doing this in spare time rather than prime time. No telling when it would be ready, or if it would ever be ready. Perhaps ss7box did what it was supposed to do, and that job is finished now.