Keynote speech, Free Software/Open Source Telephony Summit
German User's Unix Group
Geilenkirchen, Germany
January 2005
Good morning ladies and Gentlemen. Thank you for coming to Geilenkirchen
today, and will be talking to you this morning about Open Source telephony.

My name is Craig Southeren. I am based in Australia, and I am co-founder
of the OpenH323 project which is one of the most widely used Open Source
Voice-Over-IP projects. I.m no longer associated with the company that
owns the OpenH323 project, but I am still one of the principal maintainers
of the OpenH323 code. My company is called Post Increment and it provides
Voice-Over-IP consulting services as well as running the Vox Gratia web site
which supports OpenH323 and OPAL development.

At the 2004 Free Software and Open Telephony Summit, I made the prediction
that 2004 was the year that Voice-Over-IP would take off. I was not alone
in making that prediction, and looking back over the past year, I don.t
think that there is any doubt that this prediction was correct. To show why,
I would like to look briefly at the state of Voice-Over-IP during the
tech-bubble of 2000, which some people claim was when the Voice-Over-IP boom
really started, and compare that to the state of Voice-Over-IP here at the
start of 2005.

In 2000, Voice-Over-IP was active in two areas. Consumers, both business and
private, were focused on using Voice-Over-IP for toll-bypass. Companies like
Net2Phone and DeltaThree were selling calling cards or soft-phone clients
that allowed customers to save money on outgoing calls by offering cheaper
alternatives to the high prices charged by PSTN carriers for long-distance
and international calls. These Voice-Over-IP calls were still charged on a
per-minute basis, but usually at a much lower cost . sometimes as much as 1
percent of the cost of the same call over PSTN. Incoming Voice-Over-IP calls
were not normally supported, and if they were, it was primarily for IP to IP
calls within the vendor.s network. The key point is that most products were
intended to offer savings on making calls, but were not intended to be a
replacement for owning a regular PSTN phone. Interestingly, at this time
very few, if any, of the major telcos offered consumer Voice-Over-IP
services or products.  

The second area where Voice-Over-IP technology thrived during the 2000 boom
was the enhancement of value-add PSTN services such as calling cards, call
centres and interactive voice response systems. The focus for these was not
on Voice-Over-IP technology for primary content delivery, but to use
Voice-Over-IP behind PSTN to simplify delivery of PSTN applications.

Now, fast forward to the present day. 

In 2005, Voice-Over-IP and indeed the whole PSTN network is in the middle
of a massive upheaval, partially due to the pressure from Voice-Over-IP but
also due to the rapid uptake of cellular phones. Voice-Over-IP is now very
often the preferred method for new application development and for
long-distance trunking infrastructure

The cost of landline PSTN calls has dropped dramatically since 2000, to the
point where it can now compete on a price basis with Voice-Over-IP -only
calls. In fact, in a lot of cases a PSTN call is a Voice-Over-IP call -
albeit probably over a private IP network rather than the public Internet. 

Unlike 2000, there are now many companies offering Voice-Over-IP products as
a complete replacement for a conventional PSTN phone. VONAGE is one of the
most well-known, but now even major telcos are offering Voice-Over-IP
products and services. For example, AT&T and Sprint are just two of the big
US telcos that are selling consumer Voice-Over-IP products. 

We.ve just covered very quickly how Voice-Over-IP has changed up till 2005.
But I.m sure that everyone in this room would much prefer to know where
Voice-Over-IP is headed in the future. Not only is that much more interesting,
but it.s much more likely to earn us money. I.d like to offer my opinion of
where Voice-Over-IP is going based on personal observations, and on my view
of the Voice-Over-IP industry from the inside. And, because I am interested
in Open Source and because this event is the Free Software and Open Source
Telephony Summit, I will be pointing out some issues that I think are
relevant to using Open Source software during the current Voice-Over-IP boom.

One of the major drivers for the changes in the Voice-Over-IP industry has
obviously been the uptake of broadband Internet connections.

Five years ago, the majority of non-business Internet users had dialup
modems. Voice-Over-IP applications had to use compressed codecs, usually
G.723.1 or G.729. This was a barrier to Open Source Voice-Over-IP because
these low-bandwidth technologies are patented and cannot be used without
paying license fees. Even more importantly, good implementations of these
codecs cannot be distributed in source code form, and so are incompatible
with Open Source and Free Source software.

Today, broadband is the dominant Internet delivery method. To give some hard
figures on this: broadband in the US grew by 36% during 2004 alone, and
broadband now accounts for 54% of all US Internet connections. This figure
is expected to exceed 70% by the end of 2005. These figures are from Neilsen,
and assume that broadband is a connection with a speed greater than 64
kilobits per second.

Broadband allows Voice-Over-IP calls to be delivered using uncompressed
codecs such as G.711. This means that the call should have the same audio
quality as a PSTN call, because this is the same codec used by ISDN by TDM.
This is a very important point, because audio quality has traditionally been
one of the big barriers to the adoption of Voice-Over-IP. 

In one stroke, widespread broadband penetration removes one of the biggest
hurdles to Open Source Voice-Over-IP development. Open Source developers can
now use patent-free audio codecs such as G.711 without losing the majority
of users. VONAGE in the US has demonstrated that this is true . they have
400,000 customers, most of whom use G.711 for their calls.

So now, we have Voice-Over-IP calls that have approximately the same audio
quality as a PSTN call. That.s not really much of an achievement, because
PSTN calls are limited to a maximum frequency of about 4000 hertz, as that
is the minimum range needed to ensure that most human speech patterns can be
recognized. But if a broadband connection is being used, there is no reason
why Voice-Over-IP calls should be constrained in this way. A packet switched
Voice-Over-IP call is not restricted in bandwidth in the same way as a
circuit switch call is, so a Voice-Over-IP endpoint can offer improved voice
quality by using, a faster sampling rate, such as 16 kilohertz. An obvious
next step is to improve the conference calls by using full stereo effects
or even 5.1 surround sound. 

I know that at least one vendor has implemented so-called .high quality.
Voice-Over-IP calls, but that vendor has not provided any technical
information to allow verification of this claim. Even so, users claim that
they can hear the difference. I predict that better audio quality than PSTN
will become a driver for the adoption of Voice-Over-IP over traditional PSTN
in the next year or so. I also feel that this is one area where Open Source
has a real opportunity to be a leader rather than a follower, and I look
forward to seeing, or should I say, .hearing. of new developments in this
area.

Another technology that becoming synonymous with Voice-Over-IP is WiFi.
Hotspots for WiFi are everywhere these days. They can be found in airports,
restaurants, cafes and schools. WiFi technology is readily obtainable to
consumers, and many users have their own home WiFi network

(ask audience how many have their own home wifi network)

WiFi works wonderfully with Voice-Over-IP. I frequently use Voice-Over-IP
over my home WiFi network, and in the last three months, I have made
Voice-Over-IP calls from WiFi hotspots in Narita Airport in Japan, and in
Changi Airport in Singapore without any problems.

For consumers who want to make calls without a PC, there are several WiFi
handsets available that use SIP natively. There are also dual-mode cellphones
that can make calls using either conventional cellphone GSM or Voice-Over-IP
over WiFi. 

The synergistic combination of WiFi and Voice-Over-IP presents many
opportunities for Open Source developers. One such opportunity is the
software used for WiFi hotspots, many of which are based on Open Source
software. There is an obvious need for a WiFi hiotspot software package that
includes a SIP or H.323 proxy, as this would simplify NAT traversal for
Voice-Over-IP endpoints 

Another opportunity that WiFi offers for Open Source developers is in the
area of embedded software. Many consumer WiFi devices can be retrofitted
with new firmware, (the excellent Linksys WRT54G comes to mind), but there
are also many companies developing new WiFi hardware that are looking for
Voice-Over-IP applications and libraries.

Voice-Over-IP and WiFi are obviously complementary technologies, and I think
we all agree they will continue to accelerate each other.

As one of the co-founders of the OpenH323 project, the change in focus from
H.323 to SIP has been of particular interest to me. For some strange reason,
it.s often assumed that I because I have worked with H.323 for many years,
I must therefore hate SIP. 

So I.d like to make something very clear. It is not true that I like H.323
and hate SIP. I hate both H.323 and SIP exactly the same. They are both very
complicated, and they are both difficult to implement correctly, but they
both have very important advantages and disadvantages. I.ll not bore everyone
here by going over this old argument again, but if anyone is interested, we
can discuss it in depth later today, or preferably, later tonight over a few
drinks. 

What is not in question is that five years ago, the major Voice-Over-IP
protocol was H.323, but now, SIP is the dominant protocol for Voice-Over-IP
client software. The picture is less clear for applications in the network
core, as evidence says that more than 50% of calls using Voice-Over-IP leg
still use H.323 at somewhere. But the evidence is also clear that the
majority of calls that use Voice-Over-IP end-to-end use the SIP protocol,
and while H.323 will be with us for many years yet, it.s use is definitely
on the decline.

For Open Source developers, this is good news. The complete SIP specification
is very complex and (at last count) was the subject of 55 different RFCs,
but the essential concepts of SIP are simple to understand. Writing code
that can create and maintain a simple SIP session is quite easy for a
programmer of even modest skills, which means that an Open Source developer
needs less time to get results. That can only be a good thing.

But in this simplicity lies a subtle trap for Open Source developers. Very
often, programmers seem to conclude that it is simpler to write a new SIP
stack, rather than to use one of the existing excellent Open Source
implementations. This is leading to a proliferation of Open Source SIP
stacks, each with their own problems and incompatibilities. To me, this
indicates that developers, Open Source and Closed Source, are wasting time
finding and fixing problems that other people have already found and solved.
I find this confusing because one of the strengths of Open Source is supposed
to be the elimination of duplicated effort by allowing sharing of code, but
this does not appear to be the case for SIP stacks. Time will tell if this
trend continues.

So, if you are involved in project that needs a SIP stack, then please
reconsider whether you really need to re-invent the wheel again. If you do
decide that you need to write another SIP stack, then please consider making
the code Open Source, and do it now rather than waiting until the code is
finished. The sooner you make your code available, the more chance you might
get someone else to help you debug your code, and the more likely you will
stop someone else from duplicating your mistakes.

Traditionally, telcos have always attempted to lock-in their customers by
using proprietary or undocumented standards. When they are forced to use
documented standards, telcos usually add protocol extensions that lock out
competitors. Computer companies often use the same strategies, so it amall
wonder, then, that Voice-Over-IP providers, which are both telcos and
computer companies are using the same strategies.

A good example of this is the popular Skype program and network. 

(ask audience who has heard of Skype, and who has used Skype)

From a user.s perspective, Skype is a great system. It transparently works
through most kinds of NAT and firewall, and it is available for a wide
variety of platforms including Linux, Windows, MacOSX and PocketPC. The call
quality is mostly excellent, and it supports video, text chat. Best of all,
it is free to download, free to register, and free to make person-to-person
calls. I have heard that some companies now depend on Skype for all of their
international calls.

Skype is a classic example of a vendor using a proprietary protocol to lock
in their customers. The Skype protocol is completely closed and is
inaccessible to developers, except through their proprietary interface which
has limited functionality. There is no chance of writing an Open Source
client for Skype . if you don.t have one of the approved host configurations
(say, you have a Power PC Linux machine) then you are out of luck.

More seriously, there is no means of verifying any claims that Skype make
about their system. As an example, Skype claim on their website that the
client program .automatically encrypts everything before sending it through
the internet.. For a start, this claim is verifiably false . anyone can use
Ethereal to see that the Skype username is sent as clear text. 

So lets assume that Skype.s statement actually means that the audio data is
encrypted. Skype engineers have apparently stated that RSA is used to encrypt
the audio data, but because the protocol is undocumented, there is no way to
verify this. And even if it is true, we have no way of knowing if the audio
data is encrypted end to end, or if it is decrypted and re-encrypted at
every node in the network. And remember . Skype is supposed to be a .peer to
peer network. just like Kazaa, so this is a very important difference.
Potentially, your .secure. call could be available to every peer that your
call traverses. 

Now, it is only fair to point out that most Voice-Over-IP networks don.t
offer encryption at all; so any encryption, even bad encryption, maybe better
than what you are using now. But if you do care about security, then you have
no way of verifying whether Skype.s claims are true or not.

If Skype was based on an open standard, such as SIP or H.323, then other
companies and individuals could write clients that would interoperate with
their network, and it would be possible to verify the claims about security.
The same could be done if Skype provided an Open Source client, even if it
used a new protocol. But Skype have chosen to do neither, and so I feel that
Skype is a risky option for companies that depend on Voice-Over-IP for their
business

The speed at which user have embraced Skype and the other closed-source and
closed-protocol Voice-Over-IP networks such VONAGE and CallVantage shows that
the users are comfortable with using a Voice-Over-IP network, provided it
solves problems such as NAT traversal and had good audio quality. This
situation seems, to me, to be a perfect opportunity for the Open Source
community to provide an alternative network that is not locked into a
particular vendor. The Free World Dialup network from Jeff Pulver, and IAXTEL
from Digium are both attempts to provide this, but they are limited in scope
as they are both locked into specific Voice-Over-IP protocols. I would like
to see a protocol-independent addressing network that is not controlled by
any one vendor. This network should allows users to find each other and to
make calls. I think that DNS is an obvious answer to this question, not
using ENUM, but using email addresses.

I.d like to finish my talk with a discussion of software licenses. When my
business partner and I decided to release OpenH323 as Open Source in 1999,
one of the most important decisions we had to make was the software license
to use. We had two requirements that drove the license selection process. 

The first requirement is that the license we chose had to require developers
to return their code modifications back to the community. We felt this was
necessary if we were to prevent the software from being hijacked by
developers who would use the software, but not contribute their changes back
to the community.

Secondly, we needed the license to permit combining the code with other
non-Open Source code; but without the entire combined program needing to be
released as Open Source. We needed this in order for us to fulfill our goal
of using OpenH323 to earn a living which would allow us to create more even
more Open Source software. This would also allow the use of patented codecs
such as G.723.1 which we considered essential if OpenH323 was to be accepted
as a real alternative to closed source stacks. 

After much discussion and investigation, we had a short list of four Open
Source licenses that were candidates for our license. The first was the well
known Gnu General Public License, known as the GPL. This is the most popular
and well known license for Free Software, and it is in the unique position
of having a full time advocate in the person of Richard Stallman. Given the
amount of software available under this license, we had to consider it
seriously. In the, however, we had to reject it because of paragraph 2b of
the GPL.

This paragraph is the famous .viral license. clause that only requires any
software program that contains GPL code to also be GPL. As the GPL requires
free distribution of source code, this prevents GPL code from being used
with non-Open Source software like patented codecs. For this reason, we
rejected the GPL for OpenH323. 

We also considered the Lesser GPL, or LGPL. This license seemed well suited
to us, because it is compatible with the GPL but still allows code to be in
the saeme program with non-GPL contributions. Unfortunately, the language
used in the LGPL is not clear. The license text seems almost to be a
commentary on Free Software rather than a clear statement of license
conditions. For this reason, we decided that the LGPL was not specific
enough and so was not suitable for OpenH323.

We considered the BSD license which is among the most open of all of Open
Source licenses. After reading the license text, we decided that the only
purpose of the BSD license is to disclaim responsibility for damages arising
from any use of the code. Because the license does not place any restriction
on how developers can use the code, we could not use it for OpenH323 because
there was no requirement for developers to contribute their changes back to
the project.

In the end, we chose the Mozilla Public License, or MPL, which was originally
created by Netscape for the Mozilla web browser. The MPL requires any
modifications to the code to be returned to the project, but it is missing
the .viral. property of the GPL that spreads to the entire program. Because
of this, our code can be combined with code using other licenses such as the
GPL, or even closed source code. 

Six years later, I still think we made the right license choice, even though
our decision not to choose the GPL has caused contention among our friends in
the Open Source and Free Software communities. Our selection of a commercial
friendly license means that many companies have selected OpenH323 instead of
purchasing a closed-source H.323 solution. Some of those companies are now
active contributors to the OpenH323 code base, and those contributions are
now available to everyone, including many developers in projects that use
the GPL. If we had chose the GPL instead, then those contributions would be
lost, and the project would be much poorer for it.

If you are considering the selection of license for an Open Source or Free
Source project, I would recommend that you consider whether the GPL really
meets your needs. While it is the most popular license, I feel that many
people choose it for their project without considering the many real
alternatives. 

I would like to thank our host Martin Schulte of the German Unix Users Group
for looking after us during the past three days, and for his superhuman
efforts in keeping us all happy and fed and with Internet access. I would
also like to thank CSB System International, and particularly Albert Boymer,
for providing us with a wonderful venue which make these summits very
enjoyable and much fun.

That concludes my talk for today. Thank you for your time, 

I'd be happy to take any questions.