11 Architecture
David Sugar edited this page 1 month ago

Coventry Architecture

Coventry Residential Gateway


Server Components

A Coventry server is composed of a number of individual components that interact in a standard way. Each may have it's own message event queue, dispatch thread(s), and actor dispatch framework. The header file for a component will also describe data types and classes the component may share with other components. Many internal componet-only structures may be hidden in the anonymous namespace. This is a broad overview of what each component is, and what it does.


This is not done yet, but the basic idea is that coventry will manage subscriptions and operate as a broker for publised events from various endpoints. These will then be fanned out as notify messages. Some kinds of broker obects may be internal to coventry and offer the ability for external endpoint applications to get coventry internal status. This will include application/blf, which is a bitmap compressed state of all registered endpoints.


Call handling related events are processed in the Coventry call manager. They are then proccessed in receive order by an actor dispatcher, which avoids lock contention on call data structures. Calls are composed of a call object under a unique id, and segments, each of which represents a call leg session between coventry and a single endpoint. Call state is tracked both for each call leg and the call object itself. The call objects also publish live call and state information thru a shared memory block.


This is not a component that receives event, but rather is the source of events for all other components. It's purpose is to receive and process an eXosip2 event, and turn it into a message that is then sent to other components. Onw reason for this is to minimize blocking and avoid delaying receiving new sip messages to process. Some messages, like an option ping, or challenge responses, can be handled quickly and directly here, and so do not produce additional messages.

Most often messages are directed at least initially to the registry. This is true for messages that have to be authorized, as only the registry has the means to do so. Call events may be directly sent to the call manager, and broker activity may go directly to the broker. If subscribe requests have to be authorized, they will go thru the registry first.


This component receives, spools, and feeds instance messages to destination endpoints. It may later do the same for broker notify messages and provide a spooler for cdr records.


The registry updates registration state from the config file, tracks which endpoints have active registrations, and performs authentication for events that require authorization. The registry may receive inbound invites that will be handled to the call manager after authentication, and inbound instant messatges that will be spooled out thru messages after authentication. It also receives and processes registration events and maintains a shared memory block for your coventry extensions.