Linux as a Telephony Platform
As mentioned earlier, most vendors support some form of direct PBX integration. By far the most common method of integration, in the broadest sense, is “call detail”. Virtually every PBX on the market is capable of generating call detail, also available as serial data, that can be used for call accounting systems.
Call detail is often represented by different formats from different manufacturers, and may change within different releases of the same base product. The kind of information varies from simple information on in-bound/out-bound trunk usage (for example, number called, date and time, duration and extension called from) to complete call traces, whereby every aspect of a call's passage through a PBX is detailed.
Most PBXs support “programming ports”, which are essentially serial ports hooked up to a dumb terminal or PC running a terminal program like ProComm. These programming ports are typically connected to modems to allow remote maintenance of the PBX.
The programming port is quite useful and is often overlooked. From it one can find and change every aspect of a typical PBX system, such as hunt groups, directory number assignments, ringing and restriction patterns, forwarding, feature buttons on digital sets, etc. However, each piece of telephony equipment is different in the way that it handles programming. The Fujitsu F9600 has perhaps one of the easiest command languages to integrate, in that the programming interface is represented as a shell, with a shell-like command language and predictable response strings for both successful and failed commands. This makes it ideal for use with dumb serial terminals or automatic program control.
Some systems, such as the Nitsuko 384i, implement their program port as a menu system on the assumption that the tech maintaining the switch is on a form of ANSI terminal. Others that have a serial programming interface, such as the Panasonic DBS, behave and accept commands as if they were a digital telephone set, and are more unusual. These systems require a lot of work to be usable from an application standpoint.
One universal form of integration, though not widely implemented, is SMDI. SMDI is a protocol originally developed by Bell Labs for central office automated call response equipment. SMDI, when available, is commonly used for voice mail integration.
SMDI is carried on a serial port, and involves a simple, standardized protocol for sending commands and receiving messages from a PBX. Unfortunately, SMDI is pretty much limited to identifying the origin of a call, when it appears on a “message detail” extension (e.g., the extension of an attached voice mail system), and control of “message waiting” indicator lamps on phones. However, as this functionality is useful to basic voice mail systems, we will discuss SMDI again later in this article.
Systems that do not provide SMDI use tones for signaling and integration of third party voice mail systems. These tones are DTMF, and appear on the port(s) where the attached voice mail or IVR application handles its voice path. Since this form of integration is very limited and involves voice boards, I won't discuss it further.
This leaves us with a broad class of “other” integration ports. These are typically serial ports with a custom API or communication board. They use proprietary protocols to indicate signaling and control activity as calls pass in to, or are generated out of, a telephone switch. The nature of these messages vary widely from one vendor to another.
Some vendors are very keen on providing support for third parties to develop call control applications. Harris, in particular, not only documents their primary serial control protocols (known as Harris HIL and WIL respectively), but also provide third parties with actual source code that demonstrates how to implement their protocols. Other vendors, such as Fujitsu, provide full technical documentation and specifications for their protocols to interested third parties. The English is a little poor in the Fujitsu documentation, but at least they make some effort to promote their interface (TCSI).
Alas, many vendors feel there is need to keep such information secret. Doing so has slowed the widespread development of general purpose computer telephony application interfaces and restricted development to a very limited set of players; namely, Novell TSAPI and Microsoft TAPI. This wall of secrecy limits most third parties from creating more advanced integrations around the strengths of a specific brand of equipment's feature set and permits the manufacturer to pick and choose who will be allowed to directly integrate their product.
Let's take a look at the Fujitsu F9600 PBX in detail. It includes a serial port for programming. Fault messages and system status and call detail also flow out of this port. It has an optional board with a synchronous 19.2Kbps TCSI interface known as TCSI. Considering the fact that it is a slow speed link, it seems unnecessary.
In addition, Fujitsu has their own telephony architecture built around a telephony server. This telephony server runs under SCO (ODT 3) Unix and provides a separate server for each port, as well as some application servers. A primary telephony server is used to control the TCSI interface through an Eicon HDLC/X.25 board. A second, separate server is used to control the programming port. Several applications can reside on the telephony server, each of which uses a separate server and communicates via TCP/IP sessions to the MML (PBX programming interface) and TCSI servers. In addition, an interface driver can be loaded under a separate machine running Novell Netware, along with Novell Netware Telephony Services, to provide a TSAPI interface to the PBX via the SCO machine.
The multi-tiered server structure Fujitsu uses enables applications to directly utilize TCSI services, the MML interface or a generic universal API set (TSAPI). However, it uses two separate machines and operating systems to build this structure, and each low-level server is not directly aware of potentially useful information contained in the other.
Other vendors hide the low-level interface to the PBX completely and provide only a TSAPI (or TAPI) interface for their switch. These interfaces use only the information found on one port (the call control port) and ignore information available on the programming port and the potential to create remote network administration through the universal API.
In fact, the universal API concept as expressed in TAPI and TSAPI is based on creating a model PBX call control system as a server. A single API and single protocol is used between the application and this universal server. The server is then implemented by providing a lower level driver (service provider interface) to figure out how this generic PBX model applies to the peculiarities of the vendor's specific hardware and call control model.
The single-model API fails in one of two ways. First, some features of the model API are not available under a specific vendor's low-level SPI driver due to the inability to represent and recreate specific functionality within the universal call control model. Second, really neat and unique features the vendor may support beyond the basic universal model are unavailable unless, like Fujitsu, a second direct protocol server is provided.
To solve these and other problems in advanced integration for free and open systems, I completely abandoned the universal API and single protocol hierarchical model used in TSAPI and TAPI. I feel a better solution is a multi-protocol “TServer” used as a single unified server and network point of entry for access to all services that can be made network accessible from a telephony switch:
generic call control interfaces (such as a TAPI or TSAPI call server)
network SMDI (either directly from the switch or emulated through the call control interface)
call detail recording
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide