Opportunities2

Open  source  telephony  creates  limitless opportunities.  Here  are  some  of  the more compelling ones.

Tailor-made private telecommunications networks

Some people would tell you that price is the key, but we believe that the real reason Asterisk will succeed is because it is now possible to build a telephone system as one would  a  web site: with complete, total customization of each and  every facet of the system. Customers have wanted this for years. Only Asterisk can deliver.

Low barrier to entry

Anyone can contribute to the future of communicating. It is now possible for someone with an old $200 PC to develop a communications system that has intelligence to rival the most expensive proprietary systems. Granted, the hardware would not be produc- tion-ready, but there is no reason the software couldn’t be. This is one of the reasons why closed systems will have a hard time competing. The sheer number of people who have access to the required equipment is impossible to equal in a closed shop.

IAX

The IAX configuration file (iax.conf) contains all of the configuration information As- terisk needs to create and manage IAX protocol channels. The sections in the file are separated by headings, which are formed by a word framed in square brackets ([]). The name in the brackets will be the name of the channel, with one notable exception: the

[general] section, which is not a channel, is the area where global protocol parameters are defined. This  section examines  the various general and channel-specific  settings for  iax.conf. We  will define  each parameter and then give an example of its  use.  Certain options may have several valid arguments. These arguments are listed beside the option, sep- arated with the pipe symbol (|). For example, bandwidth=low|medium|high means that the bandwidth option accepts one of the values low, medium, or high as its argument. You can insert comments anywhere in the iax.conf file, by preceding the comment text with the semicolon character (;). Everything to the right of the semicolon will be ig- nored. Feel free to use comments liberally.

Opportunities

Open  source  telephony  creates  limitless opportunities.  Here  are  some  of  the more compelling ones.

Tailor-made private telecommunications networks

Some people would tell you that price is the key, but we believe that the real reason Asterisk will succeed is because it is now possible to build a telephone system as one would  a  web site: with complete, total customization of each and  every facet of the system. Customers have wanted this for years. Only Asterisk can deliver.

Low barrier to entry

Anyone can contribute to the future of communicating. It is now possible for someone with an old $200 PC to develop a communications system that has intelligence to rival the most expensive proprietary systems. Granted, the hardware would not be produc- tion-ready, but there is no reason the software couldn’t be. This is one of the reasons why closed systems will have a hard time competing. The sheer number of people who have access to the required equipment is impossible to equal in a closed shop.

Open Architecture

One of the stumbling blocks of the traditional telecommunications industry has been its apparent refusal to cooperate with itself. The big telecommunications giants have all been around for over a hundred years. The concept of closed, proprietary systems is so ingrained in their  culture that even  their  attempts at standards compliancy  are tainted by their desire to get the jump on the competition, by adding that one feature that no one else supports. For an example of this thinking, one simply has to look at the  VoIP  products  being  offered  by  the  telecom  industry  today.  While  they  claim standards compliance, the thought that you would actually expect to be able to connect a Cisco phone to a Nortel switch, or that an Avaya voicemail system could be integrated via IP to a Siemens PBX, is not one that bears discussing. In the computer industry, things are different. Twenty years ago, if you bought an IBM server, you needed an IBM network and IBM terminals to talk to it. Now, that IBM server is likely to interconnect to Dell terminals though a Cisco network (and run Linux, of all things). Anyone can easily think of thousands of variations on this theme. If any

Slow Release Cycles

It can take months, or sometimes years, for the big guys to admit to a trend, let alone release a product that is compatible with it. It seems that before a new technology can be embraced, it must be analyzed to death, and then it must pass successfully through various layers of bureaucracy before it is even scheduled into the development cycle. Months or even years must pass before any useful product can be expected. When those products are finally released, they are often based on hardware that is obsolete; they also tend to be expensive and to offer no more than a minimal feature set. These slow release cycles simply don’t work in today’s world of business communica- tions. On the Internet, new ideas can take root in a matter of weeks and become viable in extremely short periods of time. Since every other technology must adapt to these changes, so too must telecommunications. Open  source  development  is  inherently better  able  to  adapt to  rapid  technological change, which gives it an enormous competitive advantage. The spectacular crash of the telecom industry may have been caused in large part by an inability to change.  Perhaps that continued inability is why recovery has been so slow. Now, there is no choice: change, or cease to be. Community-driven technologies such as Asterisk will see to that.

Limited Standards Compliancy

One of  the oddest  things about all  of the standards that exist in the world of legacy telecommunications is the various manufacturers’ seeming inability to implement them consistently. Each manufacturer  desires a total  monopoly, so the  concept of intero- perability tends to take a back seat to being first to market with a creative new idea. The ISDN protocols are a classic example of this. Deployment of ISDN was (and in many ways still is) a painful and expensive proposition, as each manufacturer decided to implement it in a slightly different way. ISDN could very well have helped to usher in a massive public data network, 10 years before the Internet. Unfortunately, due to its cost, complexity, and compatibility issues, ISDN never delivered much more than voice, with the occasional video or data connection for those willing to pay. ISDN is quite common (especially in Europe, and in North America in larger PBX implemen- tations), but it is not delivering anywhere near the capabilities that were envisioned for it. As VoIP becomes more and more ubiquitous, the need for ISDN will disappear.

Closed Thinking

If one compares the culture of the telecommunications industry to that of the Internet, it  is sometimes difficult to believe the two are related. The Internet  was designed by enthusiasts,  whereas contributing to the  development of the PSTN is impossible for any individual to contemplate. This is an exclusive club; membership is not open to just anyone.*

The International Telecommunication Union (ITU) clearly exhibits this type of closed thinking. If you want access to its knowledge, you have to be prepared to pay for it. Membership  requires proof  of  your  qualifications, and  you will be  expected to pay thousands of dollars to gain access to its library of publications. Although the ITU is the United Nations’s sanctioned body responsible for international telecommunications, many of the VoIP protocols (SIP, MGCP, RTP, STUN) come not from the hallowed halls of the ITU, but rather from the IETF (which publishes all of its  standards  free  to  all,  and  allows  anyone  to  submit  an  Internet  Draft  for consideration). Open protocols such as SIP may have a tactical advantage over ITU protocols, such as H.323, due to the ease with  which  one  can obtain them. Although  H.323  is  widely deployed by carriers as a VoIP protocol in the backbone, it is much more difficult to find H.323-based endpoints; newer products are far more likely to support SIP. The success of the IETF’s open approach has not gone unnoticed by the mighty ITU. It has recently become possible to download up to three documents free of charge from the ITU web site.†Openness is clearly on its minds. Recent statements by the ITU sug- gest that there is a desire to achieve “Greater participation in ITU by civil society and the academic world.” Mr. Houlin Zhao, the ITU’s Director of the Telecommunication Standardization Bureau (TSB), believes that “ITU should take some steps to encourage this.”‡

The roadmap to achieving this openness is unclear, but the ITU is beginning to realize the inevitable.

The Problems with Traditional Telephony

Although  Alexander Graham Bell is most famously remembered as the father of the telephone, the reality is that during the latter half of the 1800s, dozens of minds were working toward the goal  of  carrying voice  over  telegraph lines. These  people were mostly business-minded folks, looking to create a product through which they might make their fortunes. We have come to think of traditional telephone companies as monopolies, but this was not true in their early days. The early history of telephone service took place in a very competitive environment, with new companies springing up all over the world, often with little or no respect for the patents they might be violating. Many famous monop- olies got their start through the waging (and winning) of patent wars. It’s interesting to contrast the history of the telephone with the history of Linux and the Internet. While the telephone was created as a commercial exercise, and the telecom industry was forged through lawsuits and corporate takeovers, Linux and the Internet arose  out  of  the  academic  community,  which  has  always  valued  the  sharing  of knowledge over profit.

Asterisk and Jabber (XMPP)

The  name  Jabber  is actually  the  original  name  for the IETF XMPP protocols  (RFC 3920-3923). Since Jabber  is  by far a  better  name than XMPP,  the original name has stuck.  This protocol  was  originally designed to  be a  decentralized,  nonproprietary, open-standards messaging and presence framework. It supports offline message deliv- ery  and encryption,  and  has grown to include voice messaging,  which  Asterisk sup- ports. It is interesting to note that in the beginning, Jabber was seen as a competitor to the SIMPLE protocol, which is SIP-based. XMPP is designed as a more general protocol, and is of course XML-based.

Storing Voicemail in an IMAP Server

The ability to store voice messages in the same location as regular email is something that the telecom industry  has been promising for a long time. They called it Unified Messaging, and while most PBXes now offer some sort of unified messaging, it is typ- ically very expensive to license and implement. Naturally, Asterisk cuts through all the silliness and just allows you to have your voi- cemailbox  integrated  into  an  IMAP  environment.  There  are  several  advantages  to storing your voicemail on an IMAP  server.  When you listen  to  a  voicemail  on your phone, the message is set to the read state on the IMAP server. This means that your

email client will also note that it has been read. By the same token, if you listen to the message  from your email  client, the  voicemail will turn  off  the message notification light on any phones that are assigned to that mailbox.  Deleting a message from one place will cause it to be deleted from every place. So once deleted, the message is truly gone. This is Unified Messaging, the holy grail of voicemail to email integration, but Asterisk humbly decides not to make a big deal of it. IMAP  integration is still new functionality, so there are a few things that need  to be added  in order to get it  to function. First off, Asterisk needs to have an IMAP client installed  so  that  it can  communicate  with the IMAP  server.  Pretty much  any  IMAP server  works (even  Exchange Server),  and the authors  have  personally  tested IMAP voicemail support with both the Courier-IMAP and Dovecot IMAP servers. The IMAP server may be on the same physical machine as the Asterisk installation, or it may be on the other side of the globe. To be able to access the IMAP server, Asterisk requires an IMAP client library. This library is the University of Washington’s free IMAP client, named c-client. To install the c-client you simply need to navigate to your /usr/src di-

rectory and run the following commands:

# wget ftp://ftp.cac.washington.edu/mail/imap.tar.Z