32 Features
David Sugar edited this page 2 days ago

I originally produced and deployed Coventry prototypes based on GNU SIPWitch early last decade using early Raspberry PI 1's to residences in New Haven, and as a voip wifi access point. In restarting coventry, I have been focusing on a simpler and more dedicated design for this use case. Coventry will offer a simple to setup local sip switch that can be used entirely stand-alone or in conjunction with an upstream adapter offering both vertical application integrations and access to wider services. Coventry can also be made into a residential phone server and gateway combined with an upstream service provider or upstream apartment complex server, into a voip access point combined with a domain dialing adapter, and will become usable as a small office phone system. Coventry will be able to integrate voice, messaging, video, file and screen sharing, and facility automation as needed.

1. Local Extensions

Coventry supports a simple two (or optional three) digit dialing plan for sip extensions and intercom devices, in the range 10-89 (or 100-699). This is handled over udp SIP and I presume all extensions are either directly network reachable from the coventry server or remotely over vpn. This means via lines should only be one line, and sip messages should fit well within a short sip udp packet size limit. This eliminates routing, packet forwarding, and other network complexity when dealing with purely local calls and messaging. Having a short 2 or 3 digit dialing plan means we can pack bit maps of extension states and then notify total call state in very short messages for application servers like bordeaux.

Local extensions should be possible with any generic SIP softphone, application server, PA, door phone, camera, SIP enabled sensor, or device. Some kinds of specialized support for specific devices and user agents that have unusual requirements will also be introduced as needed for specific specialized free software devices and services, but the goal is to keep Coventry simple, effective for promoting user freedom, and as generic as possible.

2. Upstream Connectivity

Upstream adaption will be done with TCP sip. This will allow for longer packets and external routing without having udp packet fragmentation. Upstream will be used to resolve any uri that has no local endpoint or feature code. Using tcp means embedded uses need not have a ssl stack.

The upstream may well simply connect to an adapter service running on the same device as the coventry server, or it may be remote. Adapter services may be used to connect coventry to internet domain dialing, an analog gateway, tls sip trunking, an upstream tethered service or cloud calling provider, or to a larger apartment building or campus sip server. Upstream should allow separate routing for emergency services, trunking, and sms, as needed. A special upstream adapter/sbc will be created for federated calling by uri. Keeping upstream services out of the coventry server itself keeps Coventry simple.

3. IPC servies

IPC services uses posix fifo's and shared memory blocks to communicate with a running coventry server. These ipc services are accessed from bundled utility programs. Special behaviors can be directly scripted thru these utilities. A utility may for example inject messages to user extensions. For container users, these utilities might be "exec"'d, such as from docker or k8s. For stand-alone devices, the utilities might be called from a web server, such as the Alpine linux config server calling coventry utils for various operations thru lua.

Actual support for IPC services and utilities may be optional, or at least the utilities shound not be mandatory to build and install. This is because for micro-services deployments, such as in containers, some upstream adapters may be able to in effect offer some similar kinds of functionality, and do so in a more network friendly way.

4. Messaging Services

Messaging is focused on delivering simple message notification to endpoints. These are text only, and in utf8 format. They are limited to 160 characters to be consistent with both SMS and limitations in total SIP UDP message size. The intended behavior is closer to SMS or "instant messages", where text messages are delivered only to active endpoints when they are registered, and are not stored for later delivery when endpoints are offline.

Messaging features include the "system" user, which represents the coventry server, and the ability to send special /commands to a coventry system user from phone devices. This allows various kinds of text interaction with your server. A /msg command may be later added to call external utilities and scripts that can then text reply back to you. Feature settings will be handled thru /commands as well, such as to set or query call forwarding. Interactive chat outside of commands will be offloaded to a chatbot or smart chat agent like perhaps Mycroft AI.

Group messaging allows messages to be delivered to multiple extensions. There is a special "all" group that the pbx-message utility uses which allows messages to be sent to all activily registered user agents. That might eventually be used for system alerts, for a welcome message, shutdown notification, reminders, and other features.

SIP style messaging is useful for notifications, command requests, and sms texting, but not really other kinds of messaging services as such. Integrating other kinds of short or non-persistent messaging services like Mastodon toots or IRC, and fediverse activity hub protocols could also be possible. Some SIP clients and devices have adopted extended messaging protocols over RTP, including some that are e2ee secure, or use alternate messaging platforms. How this is handled is largely outside the scope of Coventry itself.

There are unique oppertunity to bridge secure messaging systems with phone clients, and the place to do so seems to be at the mobile and desktop client. Imagine something like a unified Rocket.Chat client as a universal front-end for all your communication and collaboration, talking to sip server backends like Coventry as well as offering secure messaging, screen and file sharing, etc. Imagine a unified client with ui support for facility automation.

5. Presence

Presence is currently outside of the scope of coventry, other than facilitating presence notification between devices thru the introduction of generic sip publish-subscribe-notify support. Coventry will operate transparently for sip endpoints and may also have special internal events that can be subscribed to under the system uri. If I can remap to peer to peer subscriptions I may try that, too. In the future Coventry may also parse presence related publish events and track presence state as well. Presence may also become paired with an existing chat system, such as jabber or Rocket.Chat to enable both to have consistent status for you and displayable in pbx-status.

Presence does not just mean whether a person is on the phone, but also whether they are in a room, or where they may be physically located in a facility. It could involve providing contact and determining calling behavior by presence.

6. Calling

Basic calling is supported in Coventry currently. This includes dialing a destination, inviting destination extensions, detecting busy, establishing ringing, monitoring ring counts waiting to connect, detecting answer, completing connection with ack. This also includes all associated failure states and disconnects that can happen.

IPC calling will be introduced that allows programatic establishment of calls. This will use empty sdp invites to initially ring your extension, and then ring the destination when you pick up. Some kinds of web click-to-dial scenarios will make use of this, as well as reminder services.

More advanced calling features are being introduced. These will include group calling, speed dialing, forwarding, call coverage, delayed ringing coverage, hold-transfer, feature dialing codes, etc. Other kinds of advanced or specialized calling features such as automatic call distribution for ACD agents, predictive dialing, voice and video mail, reminder services, voice prompted features and generic IVR, faxing, and hunt groups will all be handled by Bordeaux for Coventry. AI voice services will be established by integrating Mycroft AI thru a fairly generic SIP user agent that is a Mycroft AI bridge called Glenda.

7. Media Services

Coventry does not process media. This means that user extensions directly negotiate their media capabilities for peer-to-peer media over SIP thru Coventry. Extensions can establish intercept-free encrypted media sessions among themselves. Since no media passes thru Coventry, no transcoding is ever required, and we can have a high concurrent call capacity even on very minimal hardware. Also call latency is much lower since we don't have to receive and regenerate media packets. Finally, this means Coventry does not need to support all kinds of special media sessions such as file sharing, screen sharing, extended forms of secure messaging, etc. It only needs to be transparent enough to clients with such capabilities.

Coventry extensions should NOT be configured to use stun or turn. This feature should be disabled. Either turn or stun may interfere with direct peer-to-peer media connections. Instead, an upstream SBC server would offer media re-mapping for firewalls to call the outside world in the future.

Some kinds of media services, such as background music on hold, may be performed by external SIP application servers such as Bordeaux. SIP compatible pagers, dedicated intercoms, security cameras, door phones, agent display panels, agent positions and attendant consoles, and other specialized devices will also become possible to connect to coventry. I am also going to try integrating Mycroft AI thru Glenda to offer a smart interactive voice for a smart next generation phone system.

8. Emergency Services

Coventry will be able to collect geospatial data from your endpoints over SIP and provide it either to other local coventry users, or to emergency service providers, as users choose and control. Contacting and connecting with emergency services is defined by the upstream adapter and outside the scope of Coventry itself. Other forms of emergency services may include messaging and alerts that are collected and injected as messages, such as to all users. This might be things like weather alerts, for example. Or advertising (just kidding), but even that gives ideas of possibilities, even if bad ones.

Pagers and messaging can be used to announce emergency events, like fire, weather alerts, etc. These can be represented and triggered by SIP events and published from sensors, such as fire alarms. Application servers like Bordeaux could subscribe to such events and activate emergency protocols to inform local users as needed. Coventry in this sense is an intermediary for connecting these different things.

9. Facility Automation

Our facility control user agent, shutin, would talk with home assistant. The coventry sip broker can receive home events, and some control options will be offered thru SIP do, as well as thru SIP messaging. Can we also directly integrate smart lighting, sensors, hvac control, etc, and then tie these to presence and weather awareness? Of course we can. Can we control these thru voice as well? Well, that is where Mycroft AI, Mycroft Skills, and Glenda would come in...

The value Coventry brings to facility control is convergence. External facility events can be represented as SIP events which can be subscribed to and notified by other applications. Facility notifications can have services that speak on their behalf using application servers, and even interactive messaging, dtmf keypads, and voice control with any telephony device endpoint. This provides broad access to facility services leveraging existing devices that are already present, rather than having to introduce special new dedicated control devices. In this sense Coventry simply facilities facility interactions.

What about smart power and lighting management? The idea of coventry and presence can include presence in and occupancy of rooms. Having wake-on-lan packets sent automatically when people enter a room. Lightening can be optimized not just for presence but also time of day. A coventry empowered facility can optimize the environment for personal comfort and productivity as needed, while reducing power usage and long term costs.