Control managers provide a means to exercise control operations and functions with the server. Integrating control managers makes it easier to report and manipulate on internal state. Coventry is not a web service, but it does have sip. For this reason, a control manager would likely be introduced as special sip requests. Because some status info returned may be large, the tcp sip context would likely be used to handle these requests. This is different than Bayonne, which used a fifo control manager and shared memory blocks. Bordeaux, in embedded use, may offer control services in the same fashion. If so, Bordeaux may then issue some kinds of control requests over sip. Sipcraft will have web support but may also offer similar control request functionality over sip tcp. Bordeaux may also aggregate any generic stand-alone sip control utilities for any functionality shared by both coventry and sipcraft.
This is now achieved thru IPC services and possibly thru upstream adapters.
Libexec shell scripts
Libexec shell scripts are scripts that "hook" coventry server activity and events to call arbitrary code. A hook might be called for things like activating and releasing extensions, to report cdr at call termination, etc. The hook would typically be an executable script that has a common name that can be searched for in a /usr/libexec/coventry directory, and would receive input likely thru a stdin pipe.
This methodology can also be used for the /msg .. text command to activate a chat resource that is a libexec script. The script can return replies thru pbx-message or by writing to the ipc fifo directly.
To create a smaller footprint we could vendor eXosip, especially for static linking, without tls support. SIP domain calling should use tls, but we can add that as a separate border service per Troll, which also would deal with certificates. Provider tethering can work fine for telcos with sip over tcp. Tethering to a cloud could also use a border controller like Troll which would support tls. This I think simplifies configuration requirements for coventry itself as well as further reducing the server footprint. Vendor patching means we could also knock out User-Agent and add Server header. We could also disable building srv support and other complicated or specialized eXosip features that are unneeded for the coventry use case.
This currently would require both vendoring osip/eXosip for small static builds, and patching the vendor'd source for sha hash support for a non-openssl builds of eXosip. This would likely be done in osip2, which already duplicates the libcrypto md5 code, or by linking libcrypto for static builds for sha support.
Vendor support and static builds are now standardized.