CallWeaver Remote Control Architecture Document version: 1.01 Author: Benjamin Kowarsch Copyright (c) 2006 Sunrise Telephone Systems Ltd., Tokyo, Japan Permission is hereby granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, GFDL Version 1.2. This Document is provided "as is" without any warranty of any kind. 1) Objectives The prime objective of the remote control architecture is to free the CallWeaver server from any tasks which are related to handling remote interfaces so that it has all its resource available to providing telephony services. Both the presence of an embedded CLI and the embedded Manager Interface are in violation of this objective and consequently they are to be removed from the server altogether. The remote control architecture is to provide a replacement mechanism for both the embedded CLI and the Manager Interface. It will also provide a mechanism for additional remote monitoring and control services utilising SOAP, XML-RPC and IM protocol based interfaces. 2) Local CLI via UNIX domain socket based client/server architecture As a replacement for the embedded CLI, the new architecture introduces a separate standalone CLI utility which will connect via UNIX domain sockets to the CallWeaver server. +----------------+ +----------------+ | CallWeaver | <---------- client requests ----------- | CallWeaver | | server | ----------- server responses ---------> | CLI utility | +----------------+ +----------------+ Under the new architecture, the CallWeaver server will no longer load any information about command syntax and command help of loadable modules, nor will it have any information about command syntax and command help of any built-in features. Command syntax and command help will be entirely removed from the codebase. Instead, syntax and help descriptions will be stored in property lists, one for each loadable module and one for built-in features. The CallWeaver server will maintain a list of currently loaded modules on disk and it will inform connecting clients about the location of this list. When a client in need of this information connects to the server, it will obtain the location from the server and load it into its own loaded module cache. Whenever the server loads or unloads one or more modules, it will notify all connected clients that a change has occurred and the clients will then update their local caches accordingly. In addition, the CallWeaver server will also provide the location of the property lists containing the descriptions of command syntax and command help. Again, when a client in need of this information connects to the server, it will obtain the location from the server and load the relevant property lists into its own local cache. As a result, the CallWeaver server is entirely relieved of the task to evaluate command syntax and provide command help. Instead, command evaluation and help can be done entirely in the CLI client without any involvement by the server. +----------------+ +----------------+ | CallWeaver | <---- loaded module info request ------ | CallWeaver | | server | ---- module info location response ---> | CLI utility | +----------------+ +----------------+ | ^ | +----------------+ | +-----------------> | list of | --- obtain list ----+ | loaded modules | | +----------------+ | | +----------------+ +----------------+ | | loadable | --------> | command syntax | --- obtain plists --+ | modules | | and help | +----------------+ | property lists | +----------------+ 3) Remote CLI via network socket based client/agent/server architecture As a replacement for the Manager Interface, the new architecture introduces a separate standalone agent which will connect via UNIX domain sockets to the CallWeaver server and accept connections from clients via network sockets. +-------------+ +-------------+ +-------------+ | CallWeaver | <- requests -- | CallWeaver | <- requests -- | Remote | | server | - responses -> | agent | - responses -> | client | +-------------+ +-------------+ +-------------+ UNIX domain TCP/IP socket socket For each protocol to be supported, a specific agent can be provided which acts as a proxy between clients and the CallWeaver server. A SOAP/http agent would provide a SOAP interface for remote SOAP based clients while an XML-RPC/http agent would provide an XML-RPC interface for remote XML-RPC based clients. +-------------+ +-------------+ SOAP +-------------+ | CallWeaver | <- requests -- | SOAP | <- requests -- | SOAP | | server | - responses -> | http agent | - responses -> | client | +-------------+ +-------------+ +-------------+ UNIX domain TCP/IP socket socket +-------------+ +-------------+ XML-RPC +-------------+ | CallWeaver | <- requests -- | XML-RPC | <- requests -- | XML-RPC | | server | - responses -> | http agent | - responses -> | client | +-------------+ +-------------+ +-------------+ UNIX domain TCP/IP socket socket Further agents could be provided for IM based protocols, such as Jabber. +-------------+ +-------------+ Jabber +-------------+ | CallWeaver | <- requests -- | Jabber | <- requests -- | Jabber | | server | - responses -> | agent | - responses -> | client | +-------------+ +-------------+ +-------------+ UNIX domain TCP/IP socket socket 4) Security UNIX domain socket based connections between the CallWeaver server and local CLI utilities or agents can take advantage of the local filesystem's built-in access control system such as file permissions and ACLs. In addition to the filesystem's access control, the CallWeaver server can maintain a list of names of executables which should be permitted to connect. The UNIX domain socket system also allows the server to obtain information about the processes and users running the executables which are trying to connect. The server can use this information for more advanced access control. For TCP/IP socket based connections between remote clients and agents, a system of user authentication is to be used. Passwords should never be sent in clear between clients and agents. Either an MD5 challenge-response or a PKI based scheme is to be used to authenticate clients. A role based access system is to be used to grant different levels of access to different types of clients. // END OF DOCUMENT