The Linux Telephony Kernel API

Herlein explains the integration of the telephony device driver into the Linux kernel.
Modprobe and Phone Devices

If you are using kmod to automatically load kernel modules as you need them, then you will need to make sure that several aliases are defined in the /etc/modules.conf file.

First of all, the system needs to know that char-major-100 is the phonedev module. Add this line to define:

alias char-major-100   phonedev

Now the system will need to know what actual phone device modules to associate with specific minor numbers. As we learned above, this may not guarantee that the phonedev module actually assigned that minor number to the phone device at module load time, but we'll cover that in more detail below. In the following examples we'll use the telephony cards from Quicknet Technologies Inc. (www.quicknet.net). These cards have Linux drivers in the kernel and are relatively inexpensive compared to most telephony cards. Quicknet's device driver is ixj.o and the module name is ixj. This driver is used for all of their telephony card products (it's smart enough to handle the ISA, PCI or PCMCIA flavors as well as knowing which cards have which kinds of phone interface circuits). To define that Quicknet's driver is associated with /dev/phone0, add this line to /etc/modules.conf:

alias char-major-100-0  ixj
As you'll recall from the discussion of phonedev's fopen function above, phonedev will build a string of the form char-major-%d-%d and fill in the parameters with 100 (major number) and the requested minor number. In our example, attempting to open /dev/phone0 would result in phonedev attempting to load char-major-100-0. That device is unknown to the kernel module loader. The alias command above maps that string to the module name ixj. When we try to open /dev/phone0 the phondev module will autoload the ixj module for us, and then call the fopen function defined in the ixj module to open the device (assuming your kernel was built to support the kernel module loader with CONFIG_KMOD=y).

The Basic Phone Device API

A fundamental premise of the Linux telephony API is that the only thing read-from and written-to phone devices using read and write is actual audio data. This is separate from—and handled quite differently from—event type information.

Audio Data

What, specifically, is audio data, and how is it different from event data? Audio data is the result of the analog-to-digital (A/D) conversion (and possibly data compression) on the audio signal present at the microphone of the telephony device. The offhook signal resulting from picking up the phone handset is an event. The tone that results from the user pressing a digit on the phone handset is an event even though that action may also generate audio. An incoming ringing signal is called an event. In short, all non-microphone inputs are events. All microphone input (and the corresponding speaker output) is audio data. This audio data is read and written from the phone device using the standard read and write system calls.

Most phone devices will provide audio data compression in the device. In fact, for successful Internet telephony applications, some form of audio data compression is required. These compression techniques are called “audio codecs” (or codecs for short), and there are a set of commonly implemented and interoperable codecs. The Linux telephony API includes defined constants for most of these common codecs; however, a particular phone device may or may not support them all. Control of what codec is in use is handled by an ioctl system call.

One large difference in how Linux telephony API differs from what used to work with sound cards is that Linux telephony API is “frame-oriented” while sound cards are “byte oriented”. A device that is frame-oriented reads a discrete frame of data corresponding to a unit of time. This is done because all audio codecs operate on a period of audio data at a time (usually 10, 20 or 30 milliseconds' worth of data). Because use of a compressed codec is the norm for network telephony applications, this is the normal and expected mode of operation for phone devices. Sound cards do not have this restriction and are free to read and write a variable number of data bytes on any give call. The API defines “frame sizes” for each codec, and raw uncompressed audio data from the device is one of the codec choices. For example, the LINEAR16 codec (uncompressed 16-bit sound samples) has a default frame size of 240 bytes—corresponding to 30 milliseconds of data at the default 8000Hz sample rate. Every read operation from the device will result in 240 bytes of data or nothing. Of course, you can change this behavior with ioctl calls to adjust the size of a frame for uncompressed codecs.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Globe7

cherr7's picture

Globe7 has Launched its New Softphone i Linux
http://www.globe7.com/linuxsys.php
http://www.globe7.com/liregnux.php

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix