Voice-Over IP for Linux
Sample applications are included with the driver to demonstrate its use. The following are some of the immediately useful ones:
intercom.c: demonstrates the driver's capability to pass audio between multiple cards without passing the audio data through user space. The application only has to indicate which cards will talk to each other—the driver does the rest.
inter2.c: the same concept as intercom.c, only it passes the data through user space. In this example, the application has to deal with reading and writing to the device files to pass data between cards.
tpjackd.c: this is the server side of a very basic IP Telephony application. It simply waits on a TCP port for an incoming connection. When received, the phone rings. When the phone is lifted, it starts passing UDP packets with audio data to the tpjack.c program.
tpjack.c: this is the client side, corresponding to tpjackd.c.
tpjackd is the daemon application which listens for an incoming call. To use it, type this:
tpjackd dev port
dev is the name of the device and is usually /dev/ixj0, although if multiple cards are in the system, it might be /dev/ixj1, etc. port is the name of the port on which the daemon will listen for an incoming ring.
The daemon application now runs as a true daemon. It disconnects from the controlling terminal upon startup and runs only in the background, logging messages to syslog. Typical use during development is watching the logging in an xterm window by using the command:
tail -f /var/log/messages
tpjack is the calling application and is used by typing the following:
tpjack dev host portdev is the name of the device and is usually /dev/ixj0, although if multiple cards are in the system, it might be /dev/ixj1, etc. host is the name of the host running the daemon (name, not IP address). Note that the names of both hosts need to be resolvable, either by DNS or the local host's files. port is the port at which the daemon will listen for an incoming ring.
These sample programs provide an example of how to use the driver, and have the added advantage of actually working well over the Internet. The authors have used it to converse between San Francisco, California and (roughly) Dallas, Texas. The voice quality was not as good as expected using real-time protocols (RTP), but it was certainly good enough to have an intelligible conversation.
Work is progressing rapidly on the driver, so check the web site often for new versions. By the time you read this, we should be in beta testing with full support for all the card's features.
The sample code is crude and does not follow any of the standards for Voice-over IP (H.323, SIP, etc.). Support for such protocols will come later, though probably not in source code form, due to other licensing restrictions. The purpose of the initial sample code is to provide a simple means of exercising the drivers and doing simple voice.
Currently, no software for Linux supports the use of any PC-to-Phone gateway service providers (such as Net2Phone). Of course, that will also change soon.
The sky is the limit for what can be done with these cards. With the availability of Linux drivers, we can craft all manner of servers to perform telephony functions—over the Internet and with or without the normal phone network. Some of the things we might soon see include VoIP PBXs, voice-mail services, and PC-to-PC and PC-to-Phone gateways. However, the most exciting applications for this technology have probably not even been imagined yet. This is a wide-open area that is begging for the Linux crowd to start putting out cool new applications. Quicknet Technologies wants to put the device drivers in place, along with some simple libraries, to facilitate this innovation.
Additional information is available on the Quicknet web site at http://www.quicknet.net/. A new mailing list has been started to provide developers with a forum for discussing the development and use of the device driver. To subscribe, send e-mail to email@example.com; in the body of the message, type
subscribe linux -sdk your_email_address
After verifying your subscription, you can send mail to firstname.lastname@example.org. If you have any problems with it, please send e-mail to email@example.com, and we will help you however we can.
Internet PhoneJACK and Internet LineJACK are registered trademarks of Quicknet Technologies, Inc.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
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.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
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