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

Configuring Asterisk for Use with DUNDi

There  are  three  files  that  need  to  be  configured  for  DUNDi:  dundi.conf,

extensions.conf, and iax.conf.‡ The dundi.conf file controls the authentication of peers whom we allow to perform lookups through our system. This file also manages the list of peers to whom we might submit our own lookup requests. Since it is possible to run several different networks on the same box, it is necessary to define a different section for each peer, and then configure the networks in which that peer is allowed to perform lookups.  Additionally,  we  need  to  define  which  peers  we  wish  to  use  to  perform lookups.

The General Peering Agreement

The General Peering Agreement (GPA) is  a  legally binding  license agreement  that is designed  to  prevent  abuse  of  the  DUNDi  protocol.  Before  connecting  to  the

DUNDi-test group, you are required to sign a GPA. The GPA is used to  protect the members of the group and to create a “trust” between the members. It is a requirement of the DUNDi-test group that your complete and accurate contact information be con- figured in dundi.conf, so that members of your peer group can contact you. The GPA can be found in the doc/ subdirectory of the Asterisk source.

How Does DUNDi Work?

Think of DUNDi as a large phone book that allows you to ask peers if they know of an alternative VoIP route to an extension number or PSTN telephone number. For example, assume that you are connected to the DUNDi-test network (a free and open network that terminates calls to traditional PSTN numbers). You ask your friend Bob if he knows how to reach 1-212-555-1212, a number for which you have no direct access. Bob replies, “I don’t know how to reach that number, but let me ask my peer Sally.” Bob asks Sally if she knows how to reach the requested number, and she responds with, “You can reach that number at IAX2/dundi:very_long_password@hostname/extension.” Bob then stores the address in his database and passes on to you the information about how to reach 1-800-555-1212 via VoIP, allowing you an alternative method of reaching the same destination through a different network. Because Bob has stored the information he found, he’ll be able to provide it to any peers who  later  request the same number  from  him,  so  the  lookup won’t have to  go any further. This helps reduce the load on the network and increases response times for numbers that are looked up often. (However, it should be noted that DUNDi creates

a rotating key and, thus, stored information is valid for a limited period of time

Music on Hold

Any popular PBX system offers the ability to supply a source of music to be played for

callers while on hold. Asterisk allows for a lot of creativity in this regard.

Nowadays, everyone is familiar with the MP3 music format, and there is a lot of interest

in using MP3s as a music-on-hold source. The concept sure seems like a good idea, but

there are a few things that we think should be given some consideration:

• MP3 files  are extremely  complex,  and  require  a substantial  amount  of  CPU  to

decode. If you have a lot of channels pulling music from the system (for example,

people sometimes like to listen to music through their phone, or a call center may

have several callers on hold), the load on the CPU caused by all of the transcoding

of the stored MP3 files could place too much demand on a machine that is otherwise

suitable to the performance needs of the system.

• Current-generation hard drives hold a lot of data, so there may not be any reason

to worry about cutting down hard drive use. Compressed audio makes sense from

a distribution standpoint (an MP3 is a much smaller download than the equivalent

in .wav format), but once on your system, do we really care how much space they

take up?

• MP3 files don’t usually come with the right sort of licensing. ;-)

Taking all of this into consideration, we recommend that you convert your music sour-

ces into the native format of the various codecs you may be supporting. For example,

if you support µlaw for your internal phones, and G.729 on your VoIP circuits, you will

want to store your music  in both  formats  so that  Asterisk will not have to perform

transcoding to play music to calls on those channels.