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.