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