VoIP For the Rest of Us
By Dan Deveson.
Dan is an engineering consultant specializing in life-safety critical communications, and has spent over 20 years designing and deploying public safety, utility and transit voice and data systems. Dan is a recent convert to SIP, and this month he explains why in a well-founded and humorous review of key issues and historical perspective.
I’ve worked on high-availability communications systems for most of my career, and I can proudly say that much of my grey hair was earned in highly-air-conditioned raised-floor environments deploying some of the world’s largest critical public safety, utility and transit dispatch platforms.
Practically from paper tape, I like to say. (Does anybody say high-tech anymore though?)
Our business providing life-safety communications for police, fire, transit and the like presents a harsh technical reality, where failures mean somebody can die. When a 911 phone rings, it better get answered, and quickly.
Our customers don’t take kindly to outages, and they have no sense of humor when it comes to performance. More than one engineer has been shackled in a dispatch center for the duration, and our customers are not averse to putting their guns on the table in design review meetings…
As a result, most of these systems are designed with a very conservative approach, and are largely built on proprietary old-school technologies that embody the Brute Force and Ignorance theory of design. That said, our customers still yearn for the fancy features of their commercial cousins, and they don’t understand why all this talk of Convergence is bypassing them in everything but trade shows.
I’ve endured many waves of technology over the years, and finally I believe some reasonable standards have matured to enable the critical communications community to benefit from both commercial and Open Source applications.
The last time I saw this was when I was between projects with a little too much time on my hands, circa 1992. I poked around CompuServe skulking for work and discovered the first website at CERN “... where the web was born!”
http://public.web.cern.ch/public/Content/Chapters/AboutCERN/Achievements/Achievements-en.html
“Interesting…” I thought, perhaps for indexing documentation. Talk about your missed opportunities.
However, my very next project took me some years into deploying dog-slow and suspiciously green-field wireless IP solutions over trunked private radio systems. A savage communications environment, as one wag put it, with good cause.
Internet Protocol – the Hard Way
A large utility company had learned that the only reason to have many of its remote offices was to house computers for service technicians receiving their orders on IBM 3270 terminals. All field personnel had vehicles, and they had a shiny new wide-area radio system and wanted to connect those dots to save money on rent. The catch was that they had huge legacy mainframe software beyond anyone’s comprehension, and could not begin to contemplate client/server applications anew.
The customer was adamant that no code changes could be made to their existing software, and thus our mission was to emulate full 3270 terminal functionality in the front seat of bucket trucks over much of the southern U.S.. Through the magic of the Internet Protocol we were able to integrate a number of off-the-shelf components and systems, tuned for minimum smoke, as I’m fond of bragging. That base system is still in place and has been enhanced significantly over the years. Can you spell return on investment? That’s the true power of open system technologies.
So while the rest of the world was noisily dot-bombing, my friends and I quietly deployed dozens of very righteous wireless IP applications on private mobile radio systems. We pushed and prodded the envelope as best we could, rarely actually writing code, but often specifying optimizations and the like. We started with DOS TSR drivers of variable reliability under Windows 3.1, peppered with in-circuit emulators and other unpronounceable equipment strapped directly to the seat of our careers. We made it work because, well, it had to.
By religiously adhering to the formal IP standards we were able to push, pull, beg and bully a wide variety of vendors to work under one technological umbrella to achieve our customers’ goals. We never failed -- we did redefine success from time to time, but this too is good.
Recently I found myself between projects with too much time on my hands again, and I decided to look into this Voice Over Internet Protocol (VoIP) stuff for critical applications. After all, I’m a smart guy, and I thought that surely this ought to be simple enough. I lost the very first bet to myself staring at an infinite “logging in” prompt on what seemed to be a popular desktop client and service. Apparently there’s more to this than meets the eye.
Regardless, these technologies are changing the world, very quickly, and government and industrial bodies around the globe are scrambling to cope with the sudden impact on their 100 year old communications empires. I love the winds of change, and despite the undeniable truth that the Pioneers Take The Arrows, clearly something big is going on here.
Over the next few months I’m going to delve into the murky waters of VoIP, and if you’d like to tag along, I’d be pleased to work with you to suss things out.
Standards – What Standards?
Standards are good, right? Well…not everybody agrees. As an engineering type forced to wade through my share of copiously dubious technological verbosity, I’m here to tell you what you already suspect – standards are often anything but.
For some years I’ve peered over the abyss at emerging telecom standards that might open VoIP up for the greater good, and I’ve been frustrated at the sheer volume of documents that propose to make thing easier for us all. While a simplistic view should not be taken, the fact remains that aside from IP itself, and perhaps RS-232, most standards have failed to achieve their defacto goal of one-size-fits-all.
I’ve often wondered why this is. After all, on the surface one might think that any move to actually agree on a common denominator or two would be a good thing. However, the sad truth is that vested interests of significance often want to preserve and promote their existing methodologies to gain competitive advantage. Many (most?) commercial standards are proposed by a given vendor and its cohorts, and are designed to secure market footings by foisting proprietary technologies on the rest of us, often by the back door.
Thus, the creation of standards by committees of technocrats is often fraught with the waste of infighting and the horrors of vestment, and many die on the vine before seeing commercial acceptance. Make no mistake: the contributors to these committees are often our best and brightest, but know well that they are also often directed by their respective marketing arms. Unfortunately the poor customer has little insight into the real truths, as these drives for adoption of proprietary interests are lobbied with the verve of the most fervent political campaigns.
Equally insidious are your tax dollars at work.
Somehow it seems that when government gets involved in the standards business, what often results is a big bill for you, in ways that you cannot comprehend. Pity poor Europe forced into CE markings on styrofoam coffee cups.
One particular area of interest to me is the so-called Intelligent Transportation Systems (ITS) standard. This is a broad subject covering everything from fare collection to smart highways. Some years ago the U.S. Department of Transportation got involved, as most people think they should have, to bring a body of industry professionals together to mandate consensus standards that define how system components operate within a consistent framework. The framework is known as the National ITS Architecture. By specifying how systems and components interconnect, the standards seek to promote interoperability.
http://www.iteris.com/itsarch/
The thinking tax-payer would think this is good, right? As the U.S. government has about an 80% stake in funding of (for example) communications systems for transit, it only makes sense that a common framework of technology from different vendors should be stipulated. Right?
Guess again.
The net result has become probably the most substantial document I’ve ever had to wrestle. Problem is, nobody in the industry pays much attention. While the standards even go so far as to specify software subroutines for every conceivable function, an entire industry has largely ignored this document as competing vendors battle it out with proprietary solutions in the general market.
The thing is, there’s a little catch-phrase with a “shall” in about every public transit contract with federal funding that mandates these standards. So, with a lot of winking and nodding going on, vendors happily check the “compliant” box, knowing full well that their competitors are no more adherent, and nobody in their right mind will mount a protest and rock this rather leaky boat. Meanwhile, legions of consultants, apparently paid by the pound, field massive bid specs on behalf of their clients, foisting features upon users that often make no sense, and driving the costs of simple and efficient communications through the roof.
But what has this to do with VoIP, you ask?
In the research for this material I found that the venerable John Sununu, that lonely republican from New Hampshire, is working on government standards for VoIP.
http://www.eweek.com/article2/0,1759,1679410,00.asp
Now, Mr. Sununu is a well considered man (and an engineer by training), and is apparently “the most prominent ally of the VOIP community on the Hill,” but we should wonder how this will affect the rest of us. Won’t the dark forces of proprietary interest swarm any committees, doling out campaign contributions with marketing fodder attached firmly to the back of their checks?
Perhaps, but there is great hope because it seems this is a much bigger issue than most people imagine, and the designers and engineers who actually make stuff happen know it well.
Grass Roots to the Rescue
The most significant thing that the Internet has given me (aside from Google…) is a confirmation of a little working theory I like to call Survival of the (technical) Fittest. Being cloistered with geeks most of my waking hours, and rarely able to actually do anything substantial by myself, I’m often at a white board, framed by pocket protectors and deep-dish glasses. I am, in my advancing age, blessed with the privilege of being surrounded by extremely bright people, however, often with widely differing views.
Over the years I’ve seen all sorts of attempts to rend cohesion from disparate designs. I’ve found that facilitating healthy debate bubbles the best ideas to the top. This principle, embodied by the essence of peer review and flavored with occasional ego, is really how things Internet are created. Various groups, most often under the Internet Engineering Task Force (IETF) thrash out the most complex ideas and turn them into reality with a surprising efficiency and effectiveness.
Indeed almost all of the Internet’s commercial success today can be directly attributed to IETF working groups fostering a sometimes brutal reality honed by legions of on-looker sniping from the stands. The term “Flame War” knows no bounds in these circles, and this incredible set of minds, whose muse is our future, is probably the strongest standards body in existence today.
The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.
http://www.ietf.org/overview.html
While the U.S. government’s sponsorship of the original design gave rise to the technology, the Internet as we know it today is very much a grass-roots driven design. And this is a very very good thing.
To be sure there are all sorts of wayward specs under the IETF, but nowhere in the history of the world has there been a more successful cooperative development of such ubiquitous technology, and at the end to the day, the best ideas do win.
And then there is Microsoft
No sleeping giant, Microsoft has forged ahead in a variety of proprietary phases, but is embracing more open standards while presumably eschewing Open Source as a dangerous and insidious enemy.
While Microsoft rules the North American software business rather completely, it does not seem so in much of the rest of the world. I wonder how many people know how recently stable Microsoft’s operating systems actually are. Just a few years ago we could not even contemplate deploying Microsoft environments in critical communications systems, and the three-finger salute (control-alt-delete) has become second nature to a recent generation.
All snipping aside, Microsoft has wisely adopted what seems to be the key standard for moving forward with VoIP, and this is probably the first common denominator with the Open Source world since they announced the embrace of internet protocols some years ago. I think this is important, both for Microsoft and for the Open Source community; let’s make note to follow up on this later, shall we?
The VoIP Glue
A big subject, but at this point in my admittedly early investigations, I think that something from the IETF called SIP is the answer to almost any question on things communication. A bold statement to be sure; to boil the whole subject down to one simple TLA (Three Letter Acronym) may subject me to the howling ridicule of my pals, but I’ve always said that one must have the courage of one’s convictions.
Session Initiation Protocol (SIP) is a glue for a host of technologies and interfaces, and it is a glue that is malleable after it is set; it is “extensible” by English language programming tags in a manner similar to XML.
The Session Initiation Protocol is a signaling protocol for Internet conferencing, telephony, presence, events notification and instant messaging.
http://www.cs.columbia.edu/sip/
My working theory is that with SIP all things communications are possible. Many a slip twixt cup and lip, but this is one Koolaid that I’m going to…sip -;)
The folks who built this are our kind of critical-communications people, and they’re fond of pigeons too:
SIP is independent of the packet layer and only requires an unreliable datagram service, as it provides its own reliability mechanism. While SIP typically is used over UDP or TCP, it could, without technical changes, be run over IPX, or carrier pigeons, frame relay, ATM AAL5 or X.25, in rough order of desireability (sic).
(http://www.cs.columbia.edu/sip/overview.html)
Session Initiation Protocol – What it Is
Float around Google a bit and you’ll see a rapidly growing body of knowledge on the “SIP protocol”
http://www.google.com/search?hl=en&lr=&q=SIP+protocol&btnG=Search
Over the next few months I’m going to measure the hits on this query, and I predict it will make a nice upward tilting graph:
2004-10-23 365,000 hits
It won’t take you long to find the SIP Center http://www.sipcenter.com which is a great place to start our investigations.
SIP Center posts a righteous manifesto, and the crux of this technology’s benefits is embodied in the following statement:
The world of networking is undergoing a sea of change: fixed and mobile networks are converging; computing and communications are becoming inseparable. The ubiquity of IP is transforming the data infrastructure into an all-encompassing communications capability that overshadows the PSTN. At the center of this evolution is SIP: it is the mechanism that unites services across platforms, thus creating a multiplicity of new possibilities.
http://www.sipcenter.com/sip.nsf/html/SIP+Manifesto+Intro
There is a myriad of references you’ll find on the net with many tutorials and primers, but SIP Center’s basics page lays the technical groundwork nicely, should you care to wade down the garden path of specifics. I like the summary:
SIP is a catalytic protocol that delivers key signaling elements, which can turn a voice over IP network into a true IP communications network - a network capable of delivering next generation converged services.
http://www.sipcenter.com/sip.nsf/html/What+Is+SIP+Introduction
This is what our customers want, and by gum, they’re going to get it!
Go wander around a bit and check out some Internet chatter on this subject. It is extensive and growing, and one thing that excites me is that the news groups on SIP are showing hundreds and thousands of posting a month, directly indicative of a healthy market picking up steam.
http://www.google.com/search?hl=en&q=SIP+newsgroups&btnG=Google+Search
Next month we’re going to set up our own SIP client(s) and chatter a bit to experiment with the basic functionality.
D. Deveson
2004-11-01
Dan Deveson is a system engineering consultant with over twenty years experience designing and deploying life-safety critical communications systems.
Dan can be reached at http://www.transtech.net/contact.html
The SIP Center publishes articles as a service to the SIP community. The authors are solely responsibile for accuracy and the views expressed within. The SIP Center neither endorses nor validates the content of these articles.