July 2012 Telephony is dead; long live telephony

Telephony is dead; long live telephony

White paper

Ian Colville, Product Manager, Aculab

APB0331 issue 1 Page 1 of 18

July 2012 Telephony is dead; long live telephony

Introduction
“We live in interesting times.”
So said Robert F. Kennedy in 1966, before
adding a comment about those times
being “more open to the creative energy of
men than any other time in history.”
That sentiment applies equally well, if not
more so, to any time between say, 1996
and the present. Whilst we may find
further echoes of Kennedy‟s speech in
current events, his mention of „creative
energy‟ is particularly apt in relation to
what has happened in the field of
telecommunications.
The pervasiveness of the Internet, the
emergence of Voice over IP and SIP,
together with the creation of disruptive,
peer-to-peer technologies, open source,
the participation of the software giants,
and computer hardware such as smart
phones and tablets, means that
communications has been revolutionised,
such that it is light years in advance of
where it was a mere fifteen to twenty years
ago.
However, the journey is not over. There
are many business sectors related to
telephony that are apparently under threat
and could be described as being caught in
a transition phase. Diversification is often
the mantra when disruptive technologies
arrive on the scene and there‟s no doubt
that the telecoms distributor / reseller
market, to cite a prime example, 1 is
engaged in those kinds of activities.
Acknowledging that anyone offering
telephony-based services is under ever
increasing competitive pressure, this white
paper offers five key pointers to an
alternative path.
The journey is never complete, for
success is a journey, not a destination.

1
Source: „Death of the Telecom VAR in 2013‟, Jeff
Hawkes, SonicMG, Telecom and Business Insights.

APB0331 issue 1 Page 2 of 18

July 2012 Telephony is dead; long live telephony

Executive summary
For providers of telephony-based services scalability, which are all geared towards
or solutions, this whitepaper offers sage improving your overall competitiveness. An
advice on dealing with the problems you overarching proposition is that a true cloud
face in attempting to remain competitive in telephony platform will remove the need to
an increasingly aggressive marketplace. purchase or maintain specialist telephony
resources and allow you to invest in your
Migration as a strategy telephony-based application as your traffic
volumes increase.
For those with an investment tied up in
legacy equipment i.e., those selling and
shipping a hardware-based product or
delivering a service from a hardware asset,
the adage, “if it‟s not broken; don‟t fix it,” is
introduced to make the point that you
should be looking to leverage that
technology investment for as long as
possible.
However, assuming that high capital costs
e.g., to replace old, depreciated, end of life
equipment, and high ongoing costs are a
concern, the advice given is to focus on a
strategy for migrating to a new platform.
Hence the phrase “telephony is dead; long
live telephony.”

Introducing cloud-based telephony

The paper devotes a considerable amount
of space to the concept of a cloud
telephony platform or a telephony-platform-
as-a-service. That is offered as a viable
strategy to follow in relation to the migration
already mentioned. The viability of cloud
telephony is not presented as a panacea in
this paper; rather it encourages careful
assessment of the options and
opportunities, based on investigating the
benefits in line with your own
circumstances. It is only by considering
those options in detail that you can
determine if a cloud-based approach is
appropriate for your business.
For those developing telephony
applications, the benefits espoused for a
cloud-based telephony platform include
reducing the time taken to craft a given
application and as a direct result, achieving
a quicker time to market and faster return
on investment. In addition to reducing cost
(CAPEX and OPEX) and development time,
the proposal is made that a cloud-based
approach offers the benefits of accessibility;
commodity, pay-as-you-go pricing; and

APB0331 issue 1 Page 3 of 18

July 2012 Telephony is dead; long live telephony

Table of Contents

Introduction............................................................................................................... 2
Executive summary .................................................................................................. 3
Migration as a strategy ............................................................................................ 3
Introducing cloud-based telephony ........................................................................ 3
A little bit of history .................................................................................................. 5
Telephony’s relevance ............................................................................................. 5
The anatomy of a telephony application ................................................................ 5
Difficulties, real or imagined.................................................................................... 6
The legacy approach ................................................................................................ 6
The alternative, 21st Century approach................................................................... 7
Migration strategies ................................................................................................. 7
Cloud comparisons .................................................................................................. 8
It’s easy to float on the cloud .................................................................................. 8
Recommendation #1 ................................................................................................ 7
Recommendation #2 ................................................................................................ 8
Recommendation #3 ................................................................................................ 9
Making it happen with a telephony-PaaS ............................................................ 12
Recommendation #4 .............................................................................................. 12
Recommendation #5 .............................................................................................. 14
Conclusion .............................................................................................................. 14
Appendix 1 .............................................................................................................. 15
A useful Ready-Reckoner to help you make that choice .................................... 15
Appendix 2 .............................................................................................................. 16
Cloud comparisons ................................................................................................ 16
About Aculab .......................................................................................................... 18
Copyright and other notices .................................................................................. 18

APB0331 issue 1 Page 4 of 18

July 2012
A little bit of history
Since the advent of what used to be called
computer telephony integration (CTi), in
the early 1990s, the industry that it
spawned has grown and adapted to be
almost unrecognisable from its early
manifestations.
The classic example of early CTi was
„screen pop‟ functionality, which was used
by call centre agents to bring up customer
details on their console, coincident with an
incoming customer call – via either a
PABX or an ACD switch.
The new market opportunity created by
CTi enabled many enterprising, computer-
centric companies to launch a plethora of
new product ideas. Voicemail hit a peak
mid-nineties, and produced its offspring of
IVR and unified messaging. Call centres
became contact centres and dialler
technology was introduced, for better or
worse. Speech technology and voice
portals entered the fray. Large-scale audio
conferencing, once the exclusive remit of
telcos, was offered by many companies,
and third party enterprise automation
services included fax broadcast, based on
networks of computer servers in which
were installed DSP boards.
If you number yours amongst that
enterprising cadre of companies, you will
have fond memories of that time.
However, much water has since passed
under the bridge and you will no doubt be
keen to find out what the future might hold.
Read on!
Telephony’s relevance
There is a myriad of further examples of
computer-centric telephony and today‟s
essential applications will surely include
unified communications, survivable branch
automation and mobility services.
However, it seems clear that whatever
needed to be done in the past is and will
remain, essential. The difference is that
functionality rendered commonplace by
CTi and what followed in its wake, is being
provided by new means and, of course,
APB0331 issue 1 Page 5 of 18
Telephony is dead; long live telephony
telephony concerns outbound as much as
inbound calls.
Despite the proliferation of Web-based
help and customer self-service options,
which serves to illustrate that
organisations have a real need to
automate certain processes, it remains
absolutely necessary to offer customers a
voice channel. That has as much to do
with the habits of humans as with
technology.
On-line transactions and the means of
accessing such services are readily
available to an increasing number of
people, worldwide. However, very many
websites leave a lot to be desired in terms
of giving up information, and when a user
can‟t find what (s)he wants to know, the
ability to call someone is needed. That
remains true, even if making a call is
notionally the last resort and despite many
organisations having developed the habit
of hiding their contact telephone number in
some inaccessible „Web nook‟ – or even
omitting it completely.
The anatomy of a telephony
application
In essence, a telephony application is a
simple thing.
It can perform actions such as answering
or placing a call. It can be designed to play
prompts for user selection or to playback
announcements, and it can control the
detection of user input (DTMF) digits
and/or, using speech recognition, a wide
range of naturally spoken commands.
Applications can transfer or interconnect
calls and add callers to audio conferences.
They can also mute and un-mute
conference participants and control
(start/stop) recordings and, of course,
hang up a call.
What differentiates one telephony
application from the next isn‟t the
telephony – it‟s the integration of the
telephony within the encompassing
business application e.g., unified
communications.
July 2012
The industry has long gone beyond the
„bolting on‟ of an adjunct IVR platform and
nowadays, the application developer is a
key element in the mix, with his or her core
skill set being more acutely aligned to the
presentation of user interfaces, and the
handling of database interactions and
integral business processes, than the
telephony.
Therein lies a question – if telephony
applications are simple, where‟s the
„disconnect‟?
Difficulties, real or imagined
To sum up the disparity, consider that
today‟s resource pool of graduate
developers is immersed in Web services
interfaces, REST-ful APIs, and high-level,
scripting languages such as PHP, Ruby
and Python. 2 That means those trained
and competent in the vagaries of low-level
telecoms are few and far between.
On the other hand, the need to understand
the minutiae of telecoms is inherently
bound up in the APIs proffered by the
vendors of telephony resources e.g., voice
boards or DSP boards. However, in that
legacy, circuit switched environment, the
need to control low-level protocols; timing;
echo cancellation; switching; DTMF
generation and detection; call progress,
fax and modem tones; answering
machines; &etc. resulted in complex APIs
and, in most cases, the use of an
appropriately low-level programming
language.
The legacy approach
That normative approach to crafting a
telephony application is still a legitimate
methodology. Despite the shift to VoIP and
IP, the traditional architecture, which large
numbers might view as being rooted in
circuit switched technology, remains a
valid choice.
2 leverage those existing technologies for as
Source: ReadWriteWeb.
APB0331 issue 1 Page 6 of 18
Telephony is dead; long live telephony
And that‟s the key word – choice. It‟s is a
matter of developer choice and it remains
a choice for two reasons:
i) The world has yet to see the
demise of the PSTN in its
entirety (and isn‟t likely to for
some considerable time to
come; and
ii) The traditional architecture has
adapted to include the IP-
centric model that seeks to
replace it.
The continuing viability of the legacy
approach is, therefore, embodied in the
options and choices open to developers,
namely:
a) If your telephony solution needs
PSTN connectivity, you can use a
DSP-based hardware solution –
telephony cards with E1/T1 trunk
network ports;
b) If your product needs only IP
connectivity, you can use a DSP-
based hardware solution –
telephony cards with Ethernet/SIP
ports; or
c) If your intended development
requires IP connectivity, you can
use an HMP-based solution –
software with a SIP stack; and
d) If you find you still need a PSTN
connection, you can use a gateway
to interwork between the disparate
network types.
Whether you are a developer, a service
provider or even an end user, the chances
are that you still have an investment tied
up in legacy equipment. That might be in
deployed equipment used to deliver a
service or inherent to your product design
i.e., when you make a sale, you ship
„bought in‟ elements, including hardware
and third party software. That applies,
even if you are only shipping servers
loaded with a combination of software.
Either way, you are likely to want to
long as possible.
July 2012
The adage, “if it‟s not broken; don‟t fix it” is
worth remembering when the hardware
upon which your applications are currently
deployed is working fine.
However, if you are reading this white
paper, it is probably because you perceive
a limit to how long you can ship product or
sell a service, based on your current
platform. As suggested above, the timeline
might be indeterminate, but it isn‟t
indefinite and further choices are needed.
The alternative, 21st Century
approach
Not fixing it „when it ain‟t broke‟ doesn‟t
mean you can‟t buy a ticket for the next
leg of the journey. The essential need is to
„keep the lights on‟ while you develop and
introduce your next generation product,
which means maintaining your legacy
platform whilst formulating your migration
strategy.
As with the transition from PSTN/TDM to
IP/VoIP, a well-considered migration
strategy will ensure you remain able to
make the most of your assets, whilst
gaining full benefit from the new solution.
If you‟ve been used to building your
telephony-based solution using third party
hardware or software, you will appreciate
that making use of what others do well is a
good thing. When it comes to telephony
resources, the evolution from trunk cards
and voice boards to host media
processing and gateways has continued,
such that the third party resources you
need are now available as software,
running on virtual machines, somewhere
in the „Cloud
Recommendation #1
Take the time to investigate the possibilities of the cloud in a risk free environment. If
you approach that task with an open mind, your migration strategy will quickly become
clear and you will find out which ticket, to which destination, you need to buy.
APB0331 issue 1 Page 7 of 18
Telephony is dead; long live telephony
Migration strategies
Cloud take up is a growing trend as many
larger organisations, 68 percent of those
with over 20 employees, 3 are already
adopting cloud-based services. A large
percentage of private sector companies,
61 percent, are already doing the same
and of those that have not yet adopted
such services, one in four plans to do so in
the coming year, with that figure rising to
30 percent in the case of SMBs.
If you are reluctant to embrace the cloud,
there are many strategies that will enable
you to experiment and investigate its
capabilities with little or no risk. In terms of
telephony resources, it is possible to make
use of what is available for free – up to the
point of being ready to deploy a
commercial solution.
With a free developer account, you can
produce countless prototypes and try out
endless new product concepts without
having to sign up to any level of
commitment, and there is no capital
expenditure needed.
Once you have developed something to
work in the cloud, you will be able to see
that there are several options for taking it
to the next level:
1. You can choose to integrate a
cloud-based application into your
current environment, using direct
SIP to your existing equipment,
when needed; and
2. You can use the cloud for high
capacity, peak requirements and
overflow; and
3. You can then decide to develop
and deploy all new projects on a
cloud-based, pay-as-you-go
telephony platform.
3
Source: The Cloud Industry Forum (CIF).
July 2012
Cloud comparisons
One of many concerns about cloud is that
it is often difficult to separate hype from
reality, however, it can be that the public
cloud is a very cost-effective way of
procuring IT and/or services.
Take the analogy of buying or renting a
motorcar. The cloud principle states that,
for short-term use, a car rental is cost-
effective, because you only pay for what
you consume. The contrary argument puts
forward the view that, if you drive
frequently and/or for longer, owning a
vehicle makes better financial sense.
The analogy is explored in Appendix 2,
where the essential costs for comparison
are monthly outlay figures. If you paid a
flat rate, monthly fee to have the facility
(car or IT/telephony equipment) available
when needed, that can correspond to the
typical, flat fee (per seat, per month)
arrangements you get with certain
software-as-a-service offerings.
However, if costs are calculated on a pure
usage basis, the picture can be quite
different as is apparent from the pay-as-
you-go example in Appendix 2. From that
example, it seems strikingly clear that a
cloud-based, usage-based option is
fundamentally cost-effective,
notwithstanding any individual issues and
concerns beyond mere price, such as
performance, security, compliance,
service level agreements, availability, etc.
Recommendation #2
Work out some examples for yourself. Using your own data, substitute for the figures in
Appendix 2 and find out how it can work for you.
APB0331 issue 1 Page 8 of 18
Telephony is dead; long live telephony
It’s easy to float on the cloud
Telephony has become much more of a
commodity function and it‟s reasonably
clear that there is a demand for more
packaged functionality, with fewer barriers
to adoption. In such an environment, the
idea of enabling applications – specifically
those that need to use telephony functions
– to be more readily crafted, is extremely
appealing.
A common slogan for cloud is „ease of
use‟ and the development languages and
APIs available with cloud-based
alternatives should engender exactly that
– a quicker, easier, more readily
accessible programming environment.
What is needed is a software framework
that abstracts the low-level telephony and
presents users with a high-level API in a
number of general-purpose programming
languages, such as Python and the .NET
family. Python, for example, is a well-
designed, elegant language that is
accessible to coders with a background in
C++ and certainly seems to appeal to
computer science graduates. 4
Fundamentally, it is a question of
providing further options and choice by
lowering the barriers to entry and making
telephony available to more than those
initiated in its „dark arts‟.
With high-level APIs, the complex aspects
are abstracted from the low-level, such
that your developers, coders or software
engineers, however you wish to label
them, don‟t have to worry about the
asynchronous nature of telephony.
4
Source: Matt Asay; Cloud Business article in The
Register – Python wraps its coils around the enterprise,
18th June, 2012.
July 2012 Telephony is dead; long live telephony

Less code, less hassle

Very often, the business application, to
which you are seeking to add telephony
functionality, will also be written in a
general-purpose scripting language.
Therefore, using the same language
means that your developers don‟t have to
learn a new language. And it‟s no
coincidence that Python, for example, is
the fastest growing (in terms of adoption) 5
and most popular language 6 amongst
programmers today. Figure 1 – answering a call; Python example

One of the facts of life of using „C‟ is that it

produces reams of code and because of Faster, higher, stronger
that, the debug phase of a project can take
The natural result of being simple to use,
a considerable length of time. On the other
means that cloud-based telephony
hand, high-level languages mean less
applications are quick to develop, test and
code (see Figure 1) and a faster debug
deploy. A project delivered quicker costs
phase for your project. That means
less in man-hours – it‟s a simple
considerable savings will be seen later on,
argument. As product life cycles are
during support and maintenance phases,
compressing, the business goals are a
for example. With less code to maintain,
faster time to money and a quicker return
more time can be spent on real, added-
on investment.
value functionality as opposed to writing
yet another, low-level, play/record routine.

Recommendation #3
Investigate the benefits of using a cloud-based telephony development platform. By
using telephony resources in the cloud by means of high-level APIs, you can reduce the
time taken to craft a given application from months to days – that‟s two orders of
magnitude faster (from months to days, not weeks).
The end result for the business, the product company benefit, is that you achieve a
quicker time to market and see a faster return on investment. In the world of
communications, where everything is now IP-centric and software-only, what you need
to consider is breaking down the barriers and gaining advantage from a cost-effective,
cloud-based telephony resource platform.

5
Source: Indeed.com job trends graph, via The Register.
6
Source: Hacker News poll, via ReadWriteWeb.

APB0331 issue 1 Page 9 of 18

July 2012
Operational benefits of
cloud telephony
If you are the telephony service provider
or are considering becoming a provider of
hosted IP-based telephony services e.g.,
providing contact centre functionality to
business users, a cloud telephony
platform can offer significant benefits. A
cloud telephony platform is what is known
as a platform-as-a-service (PaaS).
The primary difference between PaaS and
software-as-a-service (SaaS) is that there
is no pre-written, configurable application.
The concept of PaaS is that it provides
you with access to the tools and resources
you need to help you write and deploy an
application – the purpose of which is
service delivery. A true PaaS is a cloud
computing service that removes the
complexity required for you to build your
own software stacks – you provide only
the application that forms the basis of the
service you intend to offer your business
customers.
Unlike hosting servers in your own data
centre, a telephony-PaaS is based on
technology owned and managed by a third
party that offers you a service creation
Figure 2 – Cloud deployment model
APB0331 issue 1 Page 10 of 18
Telephony is dead; long live telephony
environment. A telephony-PaaS allows
you to write your own telephony
application and connect it to the Internet; a
managed, private IP network; or the
PSTN, without having to purchase
telephony cards or software.
Application creation
As you will have read above, one of the
disruptive elements that telephony-PaaS
offerings have brought to the telecoms
market is that telephony application
development is no longer a black art with
only a limited number of developers
having the skills required to build
applications.
Cloud telephony platforms should not be
viewed as a ready-made service delivery
platform. If you have operated a hosted
service, you should think about the steps
you went through to design and specify
the hardware architecture and traditional
technology elements. Consider the
alternative of a telephony-PaaS, which,
coupled with the availability of high-level
programming languages, can reduce cost
and speed up development time.
 July 2012 Telephony is dead; long live telephony

Cost considerations Scalability in the cloud

In addition to those benefits already
presented, the fundamental principle of the
cloud is also inherent in a telephony-PaaS,
namely that the cost of implementing a
service based on such an infrastructure is
largely an operating expense. Using a
telephony-PaaS enables you to avoid
having to make a significant capital spend
on things like racks and servers, cooling
and power, or buildings, for that matter.
Coupled with the concept of being billed
only for usage, a telephony-PaaS offers
you a very cost-effective method of
launching your telephony-based
application or service. And in addition to
that, it is a supremely cost-effective way of
continuing to deliver a service. Usage-
based charges are not the same as paying
a flat rate, per month, per seat, such as is
common with hosted service delivery. True
usage-based charges mean that you only
pay for the platform time when your
application makes use of the resources
available on the platform. That is a
radically different approach, which gives
you the option of fundamentally changing
the way in which you price, sell and deliver
your service(s).
In addition to the flexible model of delivery,
scalability is cited by 66 percent of cloud
users as a primary reason for its
adoption7. In theory, the cloud offers
unlimited scalability, which means that it is
possible to have access to a platform that
could make virtually unlimited,
simultaneous phone calls.
In practice, it‟s unlikely you‟d need that
kind of capacity, however, the real benefit
comes from being able to automatically
scale up and down to accommodate burst
call volume. That need might stem from a
seasonal contact centre operation,
whether or not an incoming or outgoing
calling campaign is needed; or from a
broadcast messaging scenario, when
there is an event that warrants an increase
in call volume, such as for early warning of
an impending disaster.
With a privately owned and managed
hosted platform, you have a fixed capacity
from which to offer calls. If you exceed that
capacity, you are in the realms of having
to reject calls, albeit you‟d do that
gracefully, in a manner consistent with
how the PSTN operates. The need to
cater for anticipated peak traffic usage
means you must provision what amounts
to excess capacity that lies dormant most
of the time.

Benefit
Accessibility
Commodity pricing
Transparent scalability
Technology independence
Figure 3 – benefits of a telephony-PaaS
Summary
 The ability to access the telephony resources you need, from
wherever your application resides, at any time you want
 The ability to tailor telephony applications directly, using high-
level APIs
 Being able to take advantage of on-demand resources, reduce
costs and pass the savings on to your customers in the form of
pay-as-you-go or pay-for-what-you-use pricing deals
 The ability of the telephony resources to scale seamlessly,
allowing you to accommodate peak call volumes, business
growth or the use of resource intensive features
 The opportunity exists to gain freedom from being tied to
proprietary telephony hardware or software
 The option is available for you migrate from your existing
hardware platform in a controlled manner

7
Source: The Cloud Industry Forum (CIF).

APB0331 issue 1 Page 11 of 18

July 2012 Telephony is dead; long live telephony

Recommendation #4
Make sure that you fully consider the benefits to be derived from a cloud-based
telephony platform, which should be viewed as a service or application creation
environment. A cloud-based telephony-PaaS can not only reduce cost and speed up
development time, it also offers the benefits of accessibility; commodity pricing;
scalability; and a migration path coupled with independence from hardware and
software – to improve your overall competitiveness.

Making it happen with a

telephony-PaaS
Up to this point, the focus has been on the
benefits to be gained from using telephony
resources based in the cloud. Consider
now the methodology needed to develop
and deploy a telephony-based application,
whether it‟s e.g., an IVR, voice-broadcast
or conferencing system.
If your application is designed to add
telephony functionality to workflow
processes, the equivalent, in telephony
terms, is call flow. Those operations will be
achieved by means of your application
controlling the telephony resources via the
structured commands of your chosen API
and programming language. That, in turn,
will result in the call logic that is executed
by the telephony resources – the software
programs – that make, take or interact with
a call (e.g., play or record a message;
present a caller menu; transfer a call;
create a conference; or record a call). The
architecture is shown in Figure 4.

Figure 4 – telephony-Paas architecture

APB0331 issue 1 Page 12 of 18

July 2012 Telephony is dead; long live telephony

No specialist software is needed to plan ahead for peaks as the cloud platform
implement those telephony functions; they will scale automatically, depending on the
are accessible to you via the API and a traffic passing through, with the platform
network connection. That is the primary handling innumerable, concurrent calls.
function of any cloud-based telephony
When it comes to calls breaking out to the
platform; to provide you with telephony
PSTN or when you have to receive calls
resources, negating the need to buy
originating in the PSTN, the needed
specialist technology. To use the cloud-
functionality is managed by the cloud-
based resources, your application needs
based telephony platform vendor. The
to be registered with the cloud platform,
cloud provider will have taken care of all
via a suitable network connection and,
necessary interconnect arrangements with
once that‟s done, the call logic software
its various service provider partners and
that you have coded executes on your
any break-out to the PSTN will be through
server and exchanges information with the
those partners‟ existing, established
cloud platform when there is a call event to
gateways. Some vendors will also let you
be handled.
plumb in your own service providers. It‟s
A telephony-PaaS provider will offer you a simply a question of registering them to
developer account for free, which means the telephony platform.
that it is only when you‟re ready to roll out
Using cloud-based telephony resources in
your application that you need to spend
such a way means that the costs normally
any money – OPEX rather than CAPEX.
associated with traditional telephony
At that point, you will need to pay for
platforms and application development
inbound numbers and to be able to make
can be, largely speaking, avoided. Those
outbound calls. Subsequently, you can
costs can be summarised as below (see
make and/or take as many calls as you
Figure 5).
need. And remember, you won‟t have to

Category Commentary
Other than the option of using your existing provider and continuing the established
Service relationship, the need for a service provider contract, with a large volume traffic
provision commitment, is negated as the telephony-PaaS provider handles the interconnect
contracts arrangements. In terms of calls touching the PSTN, you only need to pay for your
inbound numbers and to be able to make outbound calls.
Maintenance and/or support contracts on server and telephony hardware and
software are not needed as the „hardware‟ resides in the cloud, where it is looked
Maintenance
after by „someone else‟ – the telephony-PaaS vendor. Routine maintenance and
and support
software upgrades are also taken care of by the telephony-PaaS vendor, such that
these need no longer be a concern.
The operating costs of providing power supplies and air conditioning, etc., in your IT
Power
complex or data centre, whether that is located in-house or rented/leased, can be
overheads
significantly reduced.
The need to buy specialised telephony hardware and server platforms in which to
Hardware house e.g., DSP boards, is removed as are the complications and expenses
procurement associated with specification, procurement, installation, configuration,
commissioning, life cycle management, etc.
If your application is data driven, your data can remain on (in) your premises (there is
no obligation to put it in the cloud); a connection simply needs to be made between it
Data storage
and your application. Most likely, that will be a pre-existing connection, which means
you won‟t have to add any costly, additional interfaces.
This is not a contentious, human resource issue. In addition to not needing to find
Staff and
and recruit coders with acute telephony experience and C language skills, neither do
support
you need engineers capable of dealing with hardware installation and configuration
overheads
issues.

Figure 5 – comparative costs; cloud vs. Traditional

APB0331 issue 1 Page 13 of 18

July 2012
l
Recommendation #5
Look closely at the operational costs associated with your current solution and analyse
where and how a cloud-based telephony-PaaS alternative can provide you with financial
benefits, in terms of real world cost savings and efficiencies.
Conclusion
Traditional telephony platforms have
served everyone well over the years and,
whether you are a developer, a service
provider or even an end user, it‟s very
likely that you have an investment tied up
in legacy equipment. With that and the old
adage, “if it‟s not broken; don‟t fix it,” in
mind, you are also very likely to want to
leverage those existing technology
investments for as long as possible.
Nevertheless, you probably perceive a
limit to how long you can ship product or
sell a service, based on your current
platform with its high capital and ongoing
costs, and you now need to focus on a
strategy for migrating to a new platform.
Your essential need will be to maintain the
status quo, whilst developing and
introducing your next generation product.
As with the transition from PSTN/TDM to
IP/VoIP, a well-considered migration
strategy will ensure you remain able to
make the most of your assets, whilst
gaining full benefit from the new solution.
When it comes to telephony resources, the
shift from trunk cards and voice boards to
host media processing and gateways has
continued, and that has meant that the
resources you need are now available as
software, running on virtual machines,
provided by a third party in the cloud.
There are many strategies that will enable
you to investigate the capabilities of
telephony in (or from) the cloud, with little
or no risk. Make use of free developer
accounts, which will enable
experimentation without having to sign up
to any level of commitment or expend any
capital finances. Cloud can be
complimentary to your current
deployments, which means there is a
platform to suit your development
requirements and your customer‟s needs.
APB0331 issue 1 Page 14 of 18
Telephony is dead; long live telephony
Take the time to investigate the
possibilities of a cloud-based platform. If
you approach that task with an open mind,
your migration strategy will quickly
become clear and you will find that it will
be fundamentally beneficial. Work out
some examples for yourself, using your
own metrics and circumstances, and
establish how telephony in the cloud can
work for you.
Go beyond the theory and devote time to
investigating the benefits of using a cloud-
based telephony development platform. In
using cloud-based telephony resources
with high-level APIs, you can reduce the
time taken to craft a given application by
two orders of magnitude. The end result
for your business is that you will achieve a
quicker time to market and, consequently,
see a faster return on investment.
Make sure that you fully consider the
additional business benefits to be gained
from a cloud-based telephony-PaaS. In
addition to reducing cost and development
time, it also offers the benefits of
accessibility, commodity pricing, and
scalability, all geared towards improving
your overall competitiveness.
Finally, look closely at the operational
costs associated with your current solution
and analyse where a cloud-based
telephony-PaaS can provide you with real
world cost savings and efficiencies.
A true cloud telephony platform will
remove the need for you to purchase or
maintain specialist telephony resources
and it should allow you to invest in your
application as your traffic volumes
increase. Additionally, it should enable you
to pay-as-you-go and scale seamlessly, up
or down, when you have the need.
July 2012 Telephony is dead; long live telephony

Appendix 1
A useful Ready-Reckoner to help you make that choice
The fact is, you have a deployment choice to make, in terms of your telephony-based
application, which is to use hardware, software or the cloud.
The Ready-Reckoner grid below is intended to help you select the best platform.
Integrated Cloud-
Hardware Software
You need… media based
solution solution
gateway solution

To ‘sell and
ship’  

To ‘sell and
serve’ 

PSTN
connectivity   

IP (SIP)
connectivity   
only

IP and PSTN
  
connection

Low-level
control  

Quick time to
market 

To cut your
development 
budget

To use a
high-level
programming 
language

Figure 6 – Ready-Reckoner

APB0331 issue 1 Page 15 of 18

July 2012 Telephony is dead; long live telephony

Appendix 2
Cloud comparisons
The following is offered to illustrate that the public cloud can be a very cost-effective way of
procuring IT and/or services. It uses the analogy of buying or renting a motorcar, a dilemma
with which we can all empathise.
To reiterate, the cloud principle states that, for short-term use, a car rental is cost-effective,
because you only pay for what you consume. The contrary argument puts forward the view
that, if you drive frequently and/or for longer, owning a vehicle makes better financial sense.
Exploring the analogy, you find that to buy the car, you first need a deposit. Typically, a
deposit will be thirty percent of the purchase price, which is a non-trivial investment. To retain
ownership of the car, you are then committed to paying the balance of the price of the
vehicle, plus interest, in monthly instalments, over an extended period of time, not atypically
several years.
Note that, during that hire purchase contract term, you are also likely to take up a
maintenance or service package, which may or may not include provision for consumables
e.g., tyres, and you may even extend the warranty for an extra cost.
Ultimately, at end of the term, you own a car. However, the vehicle is worth far less than you
paid for it and when you come to replace it, the residual value is unlikely to suffice for the
deposit on the new one.
If you made the analogy real by substituting the car for an IT purchase – racks and telephony
servers – you may come up with the following example (see Figure 7):

Capital cost $100,000.00

Deposit (d) $30,000.00
Balance $70,000.00
Interest rate (annualised) 8.75%
Monthly payment $1,500.00
Term 60 months
Annual repayment $18,000.00
Total payment (p) $90,000.00
Total cost (d+p) $120,000.00

Figure 7 – IT purchase example

The key cost for further comparison is the monthly payment of $1,500.00 as that is what is
available to be spent on an equivalent, cloud-based IT service.
Revisiting the analogy, if you paid a flat rate, monthly fee to have the car available when
needed, it can correspond to the typical, flat fee, per seat, per month arrangements you get
with certain software-as-a-service offerings.
Providing hypothetical figures for such a cloud-based alternative, results in the example
below (see Figure 8).

Per seat fee $10.00 $8.00

No. of employees 100 250
Monthly outlay $1,000.00 $2,000.00
Figure 8 – software-as-a-service example

APB0331 issue 1 Page 16 of 18

July 2012 Telephony is dead; long live telephony

As before, the costs for further comparison are the monthly outlay figures, which, depending
on organisational size and numbers of users, are not too dissimilar to the original, capital
purchase alternative.
However, if the costs are calculated on a pure usage basis, the picture can be quite different.
An example of that alternative form of cloud-based service provision, procuring your IT on a
pay-as-you-go basis, results in the final example below (see Figure 9).
As this white paper is largely about options for telephony, it isn‟t unreasonable, for the sake
of example, to imagine that your IT is a telephony platform. If you‟re paying 3¢ per minute for
platform time and your call usage is reasonably typical e.g., you are not an outbound
collections agency, your monthly call volume would be in the region of 12-15,000 minutes.

Usage fee 3¢ per minute 1¢ per minute

Volume (mins) 15,000 per month 15,000 per month
Monthly cost $450.00 $150.00
Figure 9 – pay-as-you-go example

It seems strikingly clear that a usage-based cloud option is fundamentally cost-effective,

notwithstanding any individual issues and concerns beyond mere price, such as
performance, security, compliance, service level agreements, availability, etc. In a telephony
scenario as per the above examples, it means you can consume up to 50,000 call platform
minutes per month, at the 3¢ rate, before you exceed the notional budget in the capital
purchase example.

APB0331 issue 1 Page 17 of 18

July 2012 Telephony is dead; long live telephony

About Aculab
Whether you need telephony resources on a board, on a host server processor or from a
cloud-based platform, Aculab ensures that you have the choice. We are an innovative,
market leading company that places product quality and support right at the top of our
agenda. With over 30 years of experience in helping to drive our customers‟ success, our
technology is used to deliver multimodal voice, data and fax solutions for use within IP,
PSTN and mobile networks – with performance levels that are second to none.
Companies worldwide have adopted our deployment proven technology for a wide variety of
business critical services and solutions. These can include, for example, high performance
inbound/outbound contact centre applications, speech enabled IVR and self-service systems,
fax and voice broadcast, conferencing, unified communications, messaging, and hosted or
cloud-based services.
Aculab offers a support network that is as sophisticated as its products, with dedicated
account management, professional services, training, product marketing and support teams
working to understand your business and technology requirements. This enables you to
concentrate on developing market-leading solutions and remain ahead of the competition in
today‟s ever-changing communications industry.

Copyright and other notices

© 2012 Aculab plc. All rights reserved. Aculab, The Groomer, Prosody, “Connected With Aculab”, Aculab
Worldwide Digital Connectivity and Aculab Your Connection To The Future are registered trademarks of Aculab
plc. Prosody S, TiNG and GroomerII are trademarks of Aculab plc. All other product or company references or
registered and unregistered trademarks are the sole property of their respective owners.
For more information, visit Aculab‟s website at www.aculab.com
Aculab plc, Lakeside, Bramley Road, Milton Keynes. Buckinghamshire. MK1 1PT. United Kingdom. Tel: +44 (0)
1908 273 800
The information in this white paper is provided by Aculab plc, a computer telephony company, and is for
informational purposes only. Nothing in this publication forms any part of any contract.
The information contained herein is based on material, which Aculab, based on its best efforts, believes to be
reliable, but no representation is made as to its completeness or accuracy. Aculab make no warranties, express
or implied, in this document. E&OE

APB0331 issue 1 Page 18 of 18