Coventry call processing

In Sipwitch call processing was a couple of incredibly long and complex intertwined functions that used shared locks to assure coherence while operating on complex call and segment objects. In Bayonne call processing was done in parallel thru non-coupled and non-blocking async state machines for each channel, making each call leg operate rather independently. This offered incredible scalability, but also made it very difficult to synchronize call states across multiple call segments as there was no common object to represent an entire call.

In Coventry I re-thought this question and created a mini actor-like framework to handle call processing to resolve call state in a single thread which means no need for locks and guaranteed ordered operations that can be broken down and written in small self-contained blocks of code. This made it far easier to understand and maintain call processing code than Sipwitch, and made it possible to work on it peace-meal rather than having to complete a call processor all at once.

This approach has allowed me to iterate new Coventry releases while developing call processing for it, including this weekends release of Coventry. Other things being introduced include system “/” commands in messaging, as a Coventry server is meant to become a central focus for both communications and facility automation.


Coventry 0.2.6

With this weekends release of Coventry (0.2.6) I will finally have an operational call manager. True, it only handles one call leg so far (the incoming invite), but that was sufficient to validate the design and basic operation of the call manager. It also means I do expect to reach the 3rd milestone release with basic calling before the end of the year.

Assuming I do reach the objective of having basic calling operational by the end of December, I am prepared to commit to delivering a Coventry MVP perhaps as early as January. Issues like production, OS packaging, and distribution have already been successfully addressed. Naturally I would continue using gpl licensing with commercial availability.

I have also penciled in August, for various reasons, for a generally available feature complete Coventry 1.0 release supporting facility automation, residential VoIP gateways for commercial carriers, home and small office phone systems, and the production of specialized telephony products.


Coventry 0.2.2

With this weekends release of Coventry I am progressing on the sip invite call model. To meet my goals for near embedded voip gateways I am also putting together a Coventry demo kit using an original rpi 1 and Alpine Linux. I also have concluded Coventry will be the last libeXosip2 based call server I will do, although I will be using it for other kinds of things in the future.

This particular release also completes the transition for 2 and 3 digit dialing plans for supporting sipcraft and old gnu sipwitch use cases with Coventry. It also introduces support for a form of the local subnet registry trust model sipwitch once had, which can help to reduce sip message traffic.

A lot more is being done with Coventry compile-time configuration, whether for container builds or stand-alone packages. This will also become true in Bordeaux. Static builds are also often used, especially for containers, and for this reason I vendor eXosip2. For Alpine this makes it easier to support updating binary packages (apk) without using multiple repositories, since Alpine is a rapidly changing distribution.

One of the distinguishing points of all Coventry family packages is that they can be built on Alpine Linux and NetBSD, as well as for embedded targets and small containers, from source. These are also provide as standard binary packages that are built with distro specific paths, such as for Debian, but I encourage custom builds built for specific needs, such as in producing custom residential gateways.


MX Linux 21 released

MX Linix 21 is really nice. It is still systemd free, the desktop supports Xfce and KDE, and they added fluxbox, too! Like the newest Devuan release, it is now based on current stable (Debian 11).

This touches upon where I wish to develop and why I create our Debian packages without using systemd for our service daemons either. The Alpine packages will use openrc. I find no value in requiring systemd, and many reasons to avoid it where possible for creating secure and reliable systems.