Voice of IP http://blog.tmcnet.com/voice-of-ip/ en-us Copyright 2013 2012-02-28T09:05:22-05:00 hourly 1 2000-01-01T12:00+00:00 Myths and legends - cloud myths #1 http://blog.tmcnet.com/voice-of-ip/2012/02/myths_and_legends_-_cloud_myths_1.html 48879@http://blog.tmcnet.com/voice-of-ip/ zeusMyths and legends make great stories. They can make great movies – if the director is up to it. In more mundane circumstances, they’re often similarly used as a metaphor. In terms of cloud computing, some myths are considered as incontrovertible as the Instructions of Shuruppak, by which is meant – it is tantamount to a fact that this is a myth.

Myth as myth

One of those mythical statements is; “the public cloud is the most inexpensive way to procure IT services.”

Companies who promulgate this style of myth often do so for their own ends and begin by freely conceding that, yes indeed, a characteristic of the public cloud is a relatively inexpensive ‘pay-as-you-use’ model, before proceeding to ‘bust the myth’ – on their terms.

Would-be myth busters

Initially, setting the scene, these ‘axe grinders’ will indicate that the starting price for basic, on-demand instances within Amazon’s EC2, for example, is less than 10¢ per hour, based on metrics like system size, operating system, etc. Such companies usually conclude their introduction by suggesting that it’s easy to see why people think all delivery from the public cloud is cheaper than that delivered by internal IT.

It’s no surprise that the punch line comes next, when a ‘myth buster’ will typically state, with a leading ‘However’, that if you probe further, the picture will change. The changed picture presented is painted thus: for resources that are needed constantly, the private cloud is more cost-efficient than the pay-as-you-use public cloud model.

A common analogy

What usually follows is a pithy example by way of analogy, such as the comparison between renting and buying a car. The argument goes that for short-term use, a car rental is cost-effective, because you only pay for what you consume. The clincher seems to be the statement that if you drive frequently and/or for longer, owning a vehicle makes better financial sense. Does it, indeed?

Let’s explore that idea.

Truth rather than myth

The myth is stated as; “the public cloud is the most inexpensive way to procure IT services.”

In reality, what you’ve just read is a misrepresentation of the situation. The claims made for cloud computing are not presented in that fashion. It is a myth that such claims are made.

The real statement should be presented as; “the public cloud is the most cost-effective way to procure IT services.” Therein lies truth and no myth.

Unsurprisingly, the myth busters chose not to present it that way, because it’s more difficult to argue against it being cost-effective. They prefer self-fulfilling prophecies in their desire to influence behaviour.

The analogy explored

To buy the analogous car, you first need a deposit, typically thirty percent of the purchase price, which is a non-trivial investment, assuming you don’t have to borrow the cash in the first place, in which case the proposition becomes even less attractive. To retain ownership of the car, you are then committed to paying the balance of the price of the vehicle, in monthly instalments, over an extended period of time, not atypically several years.

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.

It isn’t that simple

At the end of the term, you own a car. Bully for you! However, the car is worth far less than you paid for it and (don’t forget this is merely an analogy) probably no longer ideal for the task for which it was first procured. So you buy a new car and if you’re lucky, the residual value will suffice for the deposit on the new one, but don’t count on it.

Now stop and think. You’re on the merry-go-round. You’re locked into buying car after car, forever – and a day.

Let’s look at the hypothetical outlay involved, substituting a PBX system for the car.

Capital cost

100,000.00

Monthly payment

1,500.00

Deposit (d)

30,000.00

Term

60 months

Balance

70,000.00

Annual repayment

18,000.00

APR

8.75%

Total payment (p)

90,000.00

 

 

Total cost (d+p)

120,000.00

 

In comparison

The key cost for comparison is the monthly payment of $1,500.00 as that’s what we have to spend on an equivalent, cloud-based IT service, in this case an IP-PBX. And don’t forget, that monthly cost is payable in perpetuity as long as you keep replacing and funding each new PBX in the same way. We can assume market price pressure rather neatly counteracts inflation, for the sake of simplicity.

The false trail

The myth busters would have you believe that you will pay a flat fee per seat per month for an IP-PBX, just as you do with certain software-as-a-service offerings. Thus, if you’ve got 250 employees at $10 per seat month, your monthly budget is exceeded to the tune of $1,000.00 and the idea that the public cloud is the most inexpensive way to procure IT services is, therefore, held up as a myth – because, in pure monetary terms, it’s plainly not the “most inexpensive” option.

But they’re barking up the wrong tree. You’ve already read that they’ve made a myth of a myth. Consider now, again, the real claim, which is, “the public cloud is the most cost-effective way to procure IT services.”

The whole truth

In fact, you can argue that the ‘per seat’ method is cost-effective, however, there is another model. If you are not paying a flat rate monthly fee and, instead, you’re paying on an ‘as-you-go’ usage basis, the picture is quite different. If you’re paying 3¢ per minute for platform time and your usage is reasonably typical e.g., you are not an outbound collections agency, your enterprise’s monthly call volume would be in the region of 12-15,000 minutes, which is less than $500 per month.

To put it another way, you can consume up to 50,000 minutes per month before you exceed the above notional budget. You may call that inexpensive if you wish, but you surely can’t argue against its being cost-effective.

The conclusion

Little more needs to be written. You can sum it up yourself and substitute your own figures. Whichever way you approach the issue, it’s reasonably clear that, in many typical scenarios, the public cloud can be a very cost-effective way to procure IT services.

Monthly outlay per above example

Capital purchase over term

Public cloud

 

Flat fee per seat

Pay-as-you-go

£1,500.00

£2,500.00

£500.00

 

That is what is claimed; nothing more, nothing less – and there’s no myth about it.

Of course, there are other concerns beyond mere price, such as performance, security, compliance, service level agreements, availability, etc. However, we shall consider those another day. See you next time.

***End***

Note: These calculations may be approximate, but they’re no more rough ‘n’ ready than those offered by the ‘myth busters’ and no less valid, in this context – I suggest.

]]> Tags: Related tags: , , , , ,

Related Entries TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Myths and legends - cloud myths #1

Copyright Voice of IP

]]> Cloud computing public cloud procure services inexpensive procure effective procure cloud computing cloud Tue, 28 Feb 2012 09:05:22 -0500 2012-02-28T09:05:22-05:00 The evolutional path of media processing systems http://blog.tmcnet.com/voice-of-ip/2012/02/the_evolutional_path_of_media_processing_systems.html 48783@http://blog.tmcnet.com/voice-of-ip/ evolution.jpg
From hardware based....to software based....to cloud

 Early pioneers in the market initially known as computer telephony took a look at the typical office workstation and decided that efficiencies could be achieved by integrating the two pieces of electronics typically found on workers desks – the telephone and the personal computer. They started with a computer platform, and added a hardware board to it so that the integrated computer system could make and receive phone calls. 
 
The next step was to scale the system so that it was capable of handling tens, hundreds or even thousands of channels and could be centralised and integrated with the office PBX.  To achieve this, it was necessary to have telephony boards with dedicated DSPs to perform the telephony call processing, thus leaving the main processor on the server/PBX free to handle the application. Interfaces at the E1/T1 level to TDM systems and IP connectivity for VoIP deployments were also a necessity. Media processing boards such as Aculab’s Prosody X range were designed with all these requirements in mind, and continue to form the basis of many different types of telephony server. 
Gradually, the processors used on the server platforms increased in specification, so that the main processor was not always fully utilised. It was now prudent to use the main processor to handle the media processing tasks, and thus the idea of host media processing was born. What was once only practical by using a hardware platform could now be achieved with a software only system.
From the 1990s to the present, hardware-based or software-only media processing solutions have been the two viable approaches if you wanted to create products or solutions such as:

  • Audio conferencing server
  • Video conferencing server
  • Contact and call centre servers
  • Automated diallers
  • Media and signalling gateways
  • IP media servers
  • Transcoding units
  • IVR servers and voice portals
  • Fax bureaux/Fax broadcast systems
  • Session border controllers
  • Unified messaging platforms
  • Voicemail
  • Prepaid platforms
  • IVVR systems
  • Video-enabled call centre systems
Server virtualisation, a technology that has been around a while, is now becoming the de facto approach and is revolutionising the IT industry. Once a media processing system can run on a virtual rather than a dedicated server, the server location becomes, for the most part, irrelevant, and the ownership of the server also becomes un-important. The server can be at the client site or hosted by a 3rd party – in the cloud. 

Aculab’s latest product, Aculab Cloud, takes all the telecommunications know-how gained from 20 or more years of supplying media processing hardware and software, and packages it up in the form of a PaaS (Platform-as-a-Service) – a telephony engine available for hire, if you will, able to run the same type of telephony applications (listed above) as when a dedicated server with Aculab’s hardware or software components was deployed. 
Communications systems are heading to the cloud (as with most IT systems). But if you want the more traditional hardware or software components to build your own server, then don’t worry – you can get it all from Aculab. Just think of it as the same broad-based communications capability in different form-factors. ‘Horses for courses’ as the saying goes.

Andrew Nicholson
Enhanced by Zemanta
]]> Tags: , , , , Related tags: , , , , ,

Related Entries
  • Why an IP-centric telephony board is the best choice when building highly scalable or resilient solutions - Sep 30, 2011
    Distributed_voice-based_solutions_architecture.jpg
  • Microsoft and Skype - Aug 31, 2011
  • HD Voice - it's all about connecting up the disparate islands - Jun 15, 2011
  • Convergence of the old and the new - Mar 23, 2011
    CI_logo_website.png
  • Meet the Aculab team for ITExpo East 2011 - Feb 01, 2011
    John_K_small.png
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • Voices in the clouds - Nov 30, 2010
    voices_in_the_clouds.png
  • Military manoeuvres - Oct 21, 2010
    Chinook helicopter
  • Fax server developers looking for the most cost effective development platform should see what Aculab has to offer - Oct 19, 2010
  • Heading in both directions at once - Aug 18, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: The evolutional path of media processing systems

    Copyright Voice of IP

    ]]>     Cloud computing Media Processing Aculab Aculab Cloud HMP Media processing Platform as a service media processing hardware software hardware based conferencing server dedicated server server Fri, 10 Feb 2012 13:49:11 -0500 2012-02-10T13:49:11-05:00     What do you need to run a cloud-based telephony application? http://blog.tmcnet.com/voice-of-ip/2012/01/what_do_you_need_to_run_a_cloud-based_telephony_application.html 48434@http://blog.tmcnet.com/voice-of-ip/ Traditional_vs_cloud_based_deployments.pngOk, you’re sold on the benefits of cloud computing. You understand it means you can take advantage of computing resources that are owned and managed by someone else.  That’s great!  But you want to know what that means in relation to telecommunications, if you need any additional hardware or software, who takes care of the PSTN connection, how you can access the telephony resources in the cloud, how does it compare to the traditional deployment options. In short, you want to know what you need to know, in order to be able to develop and deploy your telephony-based application, whether it’s an IVR, voice-broadcast or conferencing system.  This post intends to answer your questions.

    The application

    To start with, let’s have a look at what your telephony application is going to be doing.  It is going to add telephony functionality to your workflow processes and, in telephony terms, the equivalent is call flow.  That is achieved by means of your application controlling the telephony resources via a menu of structured commands – an API. That, in turn, results in the call logic that is executed by the software program that makes, takes or interacts with a call (e.g., plays or records a message; presents a caller menu; transfers a call; creates a conference; or records a call).

    The good news is that you do not need to purchase additional, specialist software to implement these telephony functions.  You will already have access to your programming language of choice – it’s what you’ve been using to write your business application. Apart from that, depending on the cloud telephony platform you use, there may be software to download, to help with the management of your application. Without doubt, your cloud provider should make any such software freely available to you. You shouldn’t have to buy anything extra in order to create the call logic.

    The application server

    To continue, let’s consider where your telephony application software is going to run. It’s probably going to run on the same servers you use for your business application. Yes, that means hardware. However, it doesn’t mean you have to purchase specialist machines. You can run the software alongside your other applications on your existing, premise-based servers or install dedicated ‘same spec.’ machines in your data centre. On the other hand, as discussed in my previous blog you could choose to run a virtual operation and run your application in the cloud; on Amazon or Rackspace, for example. Either way, it’s more good news.

    The telephony resources

    Moving on to the point where you have an application that can e.g., make an outbound call, transfer a call to an agent and record messages, let’s take a look at the telephony resources.  Where do those resources reside and how does the call logic that you have coded gain access to them? Here then, is some more good news to savour – you do not need to buy any dedicated telephony hardware or software. The primary function of any cloud-based telephony platform is to provide you with such resources, negating the need to buy specialist technology. Your cloud vendor’s purpose in life is to make available to you – in the cloud and on demand – a virtually [sic] inexhaustible bank of resources for your application to use.  And what makes things even better, is that you don’t have to pay for an over provision of capacity in order to cater for traffic peaks. You don’t have to pay for any volume of in house resources.

    To use the cloud-based telephony resources, your application simply needs to be registered with the cloud platform, via a suitable Internet connection. Once that’s done, your call logic software executes on your server (as above) and exchanges information with the cloud platform when there is a call event to be handled.

    The deployment

    In terms of exploring the possibilities a cloud-based platform can offer you, it gets even better. You shouldn’t need to hand over any hard cash to set up a developer account. It’s only when you’re ready to roll out your application that you need to spend any money.  At that point, you will need to pay for inbound numbers and to be able to make outbound calls.  From that moment on, you can make and/or take as many calls as you need, and you don’t have to plan ahead for peaks. The cloud platform will scale automatically, depending on the traffic passing through, and it will handle innumerable, concurrent calls. You pay for what you use, rather than pay for hardware and software or specialist technology.

    The connection to the PSTN network

    When it comes to calls breaking out to the PSTN or when you have to receive calls originating in the PSTN, the good news prevails. You do not need to buy a gateway.  Once again, the functionality is managed by the cloud-based telephony platform vendor.  The cloud provider will have taken care of all necessary interconnect arrangements with its various service provider partners and any break out to the PSTN will be through those partners’ existing, established gateways.  Some providers, like Aculab Cloud, will even let you plug in your own service providers.  It’s simply a question of registering them to the telephony platform and it’s still the case that you don’t need to buy a gateway.

    The data

    And finally… data or, more specifically, data security, can be a very sensitive point.  In truth, there is no reason why data stored on premise is any more secure than that in the cloud.  Nevertheless, you (or your customers) may not be willing to place any or all of your data in the cloud at any time, if at all (although it’s important to add that you could, if you so wished).  If your application is data driven, your data can remain on premise; a connection simply needs to be made between it and your application. Most likely, that will be a pre-existing connection, which means you won’t have to add any costly, additional interfaces. 

    Conclusion

    A true cloud telephony platform should maintain the promise of cloud computing.  It should remove the need for you to purchase or maintain specialist telephony resources or gateways and it should allow you to invest in your application as your traffic volumes increase. It should enable you to ‘pay-as-you go’ and scale seamlessly, up or down, when you have the need.
    My next blog will build on this subject, looking at migration strategies form traditional telephony deployments to cloud and will also consider some of the concerns rasied in relation to cloud.  Your thoughts and comments would be welcomed.
    Enhanced by Zemanta
    ]]> Tags: , , , Related tags: , , , , ,

    Related Entries
  • Chapter 2: Introduction to Cloud Telephony - What is a Cloud Telephony PaaS? - Oct 12, 2011
    Telephony_paas2.jpg
  • Aculab moves to the cloud at ITExpo - Jan 27, 2011
    Banner_cloud_590px.png
  • Why shouldn't you move to the cloud? - Sep 01, 2011
  • Who owns the cloud? - Sep 08, 2011
    Cloud types.jpg
  • The impact of cloud computing on the service provider market - May 13, 2011
  • "Hey, you, get on to my cloud." - Feb 04, 2011
  • The Aculab Cloud - Feb 03, 2011
    Aculab_Cloud_small.png
  • Communications technology predictions for 2011 - Dec 21, 2010
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: What do you need to run a cloud-based telephony application?

    Copyright Voice of IP

    ]]>     Cloud computing cloud communications Cloud computing Telephony API telephony platform cloud based telephony platform telephony resources based telephony telephony application cloud Thu, 26 Jan 2012 09:19:28 -0500 2012-01-26T09:19:28-05:00     The twelve Aculab products of Christmas http://blog.tmcnet.com/voice-of-ip/2011/12/the_twelve_aculab_products_of_christmas.html 48110@http://blog.tmcnet.com/voice-of-ip/
    Seasons greetings from the team at Aculab.

    Lyrics by Ian Colville, Aculab Product Manager.]]> Tags: Related tags:

    Related Entries TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: The twelve Aculab products of Christmas

    Copyright Voice of IP

    ]]>     aculab Tue, 20 Dec 2011 11:44:19 -0500 2011-12-20T11:44:19-05:00     Media processing resources - boxed! http://blog.tmcnet.com/voice-of-ip/2011/11/media_processing_resources_-_boxed.html 48111@http://blog.tmcnet.com/voice-of-ip/ “You pays your money and you takes your choice
    You can double your money or open the box.”

    Most of us like to keep things neat and tidy; everything in its place and a place for everything as the saying goes. Even those who give the impression of being chaotic have some kind of system – it may be known only to them, but they know where to find things when they need them. Perhaps that explains the apparent contradiction in the law of growing entropy – the fact that there is a ‘law’ governing the degree of disorder or uncertainty in a system.Prosody X - boxed
    In terms of provisioning a hardware-based telephony system, there are a number of areas of uncertainty. Those can range from the relatively mundane, albeit costly, errors that occur when you inadvertently damage a board whilst trying to locate it in a server, to the frustratingly frequent component obsolescence that is seemingly built-in to PC motherboards. Another issue is the march of progress that means you can no longer find servers with slots for your PCI boards, unless you are able to specify expensive riser adapters. And for how long will that continue?

    How nice would it be?
    There’s an old Scottish folk song with the line, “How nice it would be if the whiskey were free and the loch was full up to the brim.” How nice would it be if you didn’t have to worry about form factors and the ongoing procurement and Q&A of server chassis? You might then be able to afford the odd bottle of that malt you like so much. Have you tried the Glen Rothes yet?
    OK, so there’s no such thing as a free lunch, but in these days of ‘software-as-a-service’ and ‘cloud-based applications’ that would be akin to getting a free drink with your lunch and a large measure at that. That is, if you still need hardware-based systems. And anyone who needs to connect a telephony-based application to the PSTN must use hardware, for the virtual network interface has yet to be invented. Although wireless comes close.

    The magic’s in the box
    So, what’s the best way to keep things neat and tidy? As your mother used to tell you, “Put your toys in the toy box” (you can throw them out of the pram, but they must go back in the box). Even if you have a box of tricks, the magic comes from them lying neatly in their box.
    For telecommunications systems, the magic box is typically referred to as a telephony server. Those boxes are server chassis containing specialist hardware – the media processing resources needed for simultaneous TDM and IP-based applications. Accessible at the box are the obligatory T1, E1 and Ethernet interfaces – external network connections.

    Here’s how nice it can be
    How nice would it be if you didn’t have to concern yourself with:
    • The form factor of your DSP boards
    • Handling the installation of board-level hardware
    • Managing the procurement and Q&A of adequately specified server chassis
    • Expensive, high-spec server platforms for both your applications and those boards
    How nice would it be if you were able to:
    • Virtualise your application software, and run that virtually anywhere you choose
    • Distribute media processing resources where you need them, available to multiple applications
    • Use lower cost application servers, with remotely distributed devices for media processing
    How could you argue!
    The spell checker in this word processor (yes, it’s MS and, no, I don’t mean manuscript) offers fight, spar and exchange blows as synonyms for box. It suggests neither cartons nor containers, nor does it veer in the direction of struts or joists from spar. Everything is geared towards conflict, it seems. But you could hardly argue that buying media processing resources, such as Aculab’s Prosody X, pre-packaged in a 1U box, isn’t a good idea. And guess what – the idea isn’t virtual, it’s real.

    Ian Colville
    ]]> Tags: Related tags: , , , , ,

    Related Entries TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Media processing resources - boxed!

    Copyright Voice of IP

    ]]>     media processing processing resources server chassis hardware based based applications server Wed, 16 Nov 2011 11:57:42 -0500 2011-11-16T11:57:42-05:00     Chapter 2: Introduction to Cloud Telephony - What is a Cloud Telephony PaaS? http://blog.tmcnet.com/voice-of-ip/2011/10/chapter_2_introduction_to_cloud_telephony_-_what_is_a_cloud_telephony_paas.html 47676@http://blog.tmcnet.com/voice-of-ip/ If you are intrigued by Cloud Telephony, you might be asking yourself a number of questions. Those questions are likely to include: “What is meant by a Telephony Platform as a Service (PaaS)?” “Is it for me?” “When and why would I use a Telephony PaaS?” “What are the Telephony PaaS options?” Read on for some answers…

    In summary, a PaaS could be a server system or it could be a computer language interpreter that enables bespoke applications to be written and deployed.  The main benefit being that you can access ‘tools’ to help write and deploy an application, based on technology owned and managed by someone else.

    PaaS is different from Software as a Service (SaaS) in that there is no pre-written, configurable application. It’s more of a service creation environment, whereby you get access to the tools/resources you need to build a particular type of application – the purpose of which is to deliver services for which your customers (subscribers in old money) will pay.  A Telephony PaaS allows you to write your own telephony application and connect it to the PSTN, without having to purchase telephony cards or software.

    Is it for me? Does it speak my language?

    On one level, cloud computing is all about making things easier and cheaper.  It’s no different with a Telephony PaaS.  One of the most provocative or 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.  Now, thanks to the provision of APIs in high-level programming languages, just about any developer can get to grips with building IVRs or voicemail – in days, not months. 

    I can see a telephony PaaS offers some great benefits but…

    …when and why would I use it? As per an earlier blog post on different cloud types, if the thought of storing critical, personal or sensitive information in a place that to all intents and purposes is completely out of your control makes you feel a tad uneasy – you’re not alone.  The good news is that with a Telephony PaaS you don’t have to jump in at the deep end…

    …Poke your head in the clouds

    One option is to run your application on a local machine, managing and executing your code under your own control. As that is running locally, you can use whatever additional libraries, files or database you want.  The key point is that this data, and indeed the business logic contained within your application, is deployed on premise or in a private data centre. It’s just the telephony engine (platform) that sits in the cloud.
     telephony_paas1.jpg

    What is the alternative? Creating a virtual solution

    There is also the option to place the business data and logic into the cloud, on Amazon EC2 or Rackspace, for example, alongside (virtually speaking) the telephony server. It’s a bit like having your own private Telco, running on your behalf and under control of your application, but fed and watered by a Concierge. If you want to change things, you can replace or update your application remotely.

    Telephony_paas2.jpg
    Cloud telephony platforms provide a cloud-based service or application creation environment.  Coupled with the availability of high-level programming languages, a telephony PaaS, compared to traditional technology deployment options, can reduce cost, speed up development time and offer customers flexibility in terms of their cloud migration.

    Faye McClenahan
    Aculab Blogger
    Enhanced by Zemanta
    ]]> Tags: , , , , , Related tags: , , , , ,

    Related Entries
  • Why shouldn't you move to the cloud? - Sep 01, 2011
  • Aculab moves to the cloud at ITExpo - Jan 27, 2011
    Banner_cloud_590px.png
  • What do you need to run a cloud-based telephony application? - Jan 26, 2012
    Traditional_vs_cloud_based_deployments.png
  • The impact of cloud computing on the service provider market - May 13, 2011
  • A crowd of daffodils and hosted clouds - Aug 27, 2010
    IMG_6609_crop_sml.png
  • Who owns the cloud? - Sep 08, 2011
    Cloud types.jpg
  • "Hey, you, get on to my cloud." - Feb 04, 2011
  • The Aculab Cloud - Feb 03, 2011
    Aculab_Cloud_small.png
  • Communications technology predictions for 2011 - Dec 21, 2010
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Chapter 2: Introduction to Cloud Telephony - What is a Cloud Telephony PaaS?

    Copyright Voice of IP

    ]]>     Cloud computing Cloud communications cloud computing Cloud telephony PaaS SaaS software-as-a-service cloud telephony creation environment programming languages telephony application access tools telephony Wed, 12 Oct 2011 06:38:21 -0500 2011-10-12T06:38:21-05:00     Why an IP-centric telephony board is the best choice when building highly scalable or resilient solutions http://blog.tmcnet.com/voice-of-ip/2011/09/why_an_ip-centric_telephony_board_is_the_best_choice_when_building_highly_scalable_or_resilient_solu.html 47598@http://blog.tmcnet.com/voice-of-ip/ This is part two of a set of articles describing the benefits of Aculab’s range of IP-centric Prosody X media processing boards for developers of large scale communications platforms.
    In part one, it was stated that there are many advantages in having IP at the core of the Prosody X media processing board, not least of which is the high channel counts made possible by such an architecture. But that is just one aspect…

    Choosing IP connectivity enables a distributed architecture

    In putting IP technology at the heart of the Prosody X design it is much simpler, due to the ubiquity of Ethernet in IT networks, to build multi-board, multi-chassis and multi-location systems using Prosody X. So if the high channel counts of a single Prosody X board are not enough, then it is easy to build multi-board systems.

    The traditional way

    Before VoIP entered the telephony world, we depended on TDM technology and an array of disparate CAS and CCS type PSTN protocols, and most of the voice-based solutions had a common architecture, simply described as a host server with telephony boards. Voicemail, interactive voice response (IVR), call centre or fax broadcast solutions had a common architecture with all parts integrated in one physical unit.

    trad_voice-based_solutions_arch.jpg
    Figure 1 - traditional voice-based solution architecture

    The interconnection between the cards was done via the proprietary telephony bus H.100/H.110, while the high level application controlled the boards using the PCI bus that is present in the chassis or the computer server.
    Although achieving the main objective of delivering a defined functionality set within a reasonable cost, employing the traditional architecture creates a significant headache for the developers when additional sophistication from such a solution is required:
    • Scalability – difficult to add capacity with minimal added cost
    • Redundancy or adding fault tolerance – technically cumbersome to achieve and almost doubles the CAPEX

    Remote system management, hitless software upgrades, and hardware maintenance in the system without interrupting the service, also add to the comprehensive list of system requirements that lead to increased architectural complexity and spirals the cost of solutions utilising the traditional architecture.

    A better way

    What is needed is the implementation of a distributed architecture. A distributed architecture offers scalability, redundancy, remote management and high service continuity at a minimal added cost. A sample architecture is shown below. Distributed_voice-based_solutions_architecture.jpg
    Figure 2 - Distributed voice-based solutions architecture

    In choosing IP connectivity at the core of Prosody X, we enabled developers to utilise the inherent strength of IP to allow remote devices to communicate distantly and operate as if they were all present locally. So if a single Prosody X board does not offer enough processing power, then adding further media processing resources is a very simple task. Or if you wish to separate the media processing resources (DSP boards) into physically separate servers for resilience/fault tolerance, then this too is easy to achieve as the servers require just an IP connection between them.
    Many of our customers have taken advantage of this approach to build large scale systems, such as voice conferencing platforms of fax servers supporting thousands of channels of capacity. Others have used the ability to physically separate the resource boards to build fully redundant mission critical communications platforms. Whatever your requirements of a media processing platform, Prosody X offers a flexible, cost-efficient and scalable solution.
    To find out more about our latest member of the Prosody X family, visit the new 8 trunk Prosody X PCIe board page. Or for an overview of the whole Prosody X range visit the DSP based media processing page.

    Andrew Nicholson
    Enhanced by Zemanta
    ]]> Tags: , , , Related tags: , , , , ,

    Related Entries
  • Convergence of the old and the new - Mar 23, 2011
    CI_logo_website.png
  • The evolutional path of media processing systems - Feb 10, 2012
    evolution.jpg
  • SIP call recovery in gateways - Sep 02, 2011
    SIP-call-recovery
  • Microsoft and Skype - Aug 31, 2011
  • HD Voice - it's all about connecting up the disparate islands - Jun 15, 2011
  • Meet the Aculab team for ITExpo East 2011 - Feb 01, 2011
    John_K_small.png
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • Voices in the clouds - Nov 30, 2010
    voices_in_the_clouds.png
  • Military manoeuvres - Oct 21, 2010
    Chinook helicopter
  • Fax server developers looking for the most cost effective development platform should see what Aculab has to offer - Oct 19, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Why an IP-centric telephony board is the best choice when building highly scalable or resilient solutions

    Copyright Voice of IP

    ]]>     Emergency communications Media Processing VoIP Aculab DSP PCI Express Voice over IP media processing distributed architecture voice based traditional architecture large scale prosody Fri, 30 Sep 2011 11:34:48 -0500 2011-09-30T11:34:48-05:00     Dealing with RTP loss http://blog.tmcnet.com/voice-of-ip/2011/09/dealing_with_rtp_loss.html 47390@http://blog.tmcnet.com/voice-of-ip/ SIP call recovery from RTP loss. This post continues the theme, providing some more useful information – detecting and dealing with RTP loss between two SIP end points.

    If you recall the scenario, there is a gateway installed between an SS7 carrier network and an emergency services IP network – an ESInet – over which emergency calls are routed to public safety answering points (PSAPs). Calls entering the ESInet via the gateway are SIP/RTP/UDP and, as the NENA i3 specification quite rightly states, in no circumstances should an in-progress emergency call be taken down automatically, just because RTP streams fail.

    Whatever effort you put into making the call handling equipment redundant and resilient, it is always best to assume that bad things can still happen. To misappropriate the principle of simplicity from Ockham’s razor, follow the rule of thumb that advises, “Make as few assumptions as possible.” In fact, make one assumption only – expect the worst (i.e., ‘the proverbial’ happens).

    So, we can expect situations to arise in which RTP media between the gateway and the ESInet fails.

    PSAP equipment must be able to distinguish between RTP failure and real silence by a caller. That capability must apply at all points on an ESInet where RTP media is encountered by a device – from the gateway right through to the PSAP. The gateway uses technology – some form of digital signal processing, using either hardware (DSPs) or software (HMP) – to encode the media, and that same functionality will be used to detect the presence of RTP streams and distinguish between packets of silence or ‘speech’.

    So far, so good, but as suggested, in a prediction far more likely than a prophecy from a Nostradamus quatrain to come true, the worst will happen and an RTP stream will fail.

    Using SIP OPTIONS here is not entirely adequate – yes, that’s a good method of monitoring the far end, but only in so far as it confirms the presence of a signalling capability at the User Agent. A 200OK response doesn’t confirm the presence of RTP; merely that the signalling link is functioning. So, for what are we catering?

    It’s not a failure of the gateway with which we need to deal – it’s a failure from (or towards) the other end. It might be counterintuitive, but when the device at the far end fails, it doesn’t know it’s failed, because it can’t tell if the gateway has received any RTP. Furthermore, although the gateway can tell if it’s receiving RTP, it can’t tell if the other device is receiving its RTP. The point being, half the solution has to be implemented at each end in order to achieve a whole result. That is, similar signal processing functionality needs to be implemented at both ends.

    If there’s been a failure in transmitting RTP from the remote end equipment, the gateway clearly isn’t responsible. However, any gateway worth its salt can mitigate the situation by detecting RTP loss and implementing SIP call recovery as discussed in last month’s post. In addition, as part of the process of failover recovery from far end RTP loss, any decent gateway will provide management notification of RTP loss via SNMP.

    Good gateways will follow the ‘Robustness Principle’ of Jon Postel: “Be conservative in what you do, be liberal in what you accept from others.” Innovative gateways will not leave anything to chance – after all, Nostradamus never predicted anything good.

    Click on the link if you want to know more about Aculab’s range of gateways or why not post a comment – or give us a call.

    Ian Colville
    Enhanced by Zemanta
    ]]> Tags: , , , , Related tags: , , , , ,

    Related Entries
  • SIP call recovery in gateways - Sep 02, 2011
    SIP-call-recovery
  • Failover or failsafe? - Jun 18, 2010
  • Why gateways are 'how to' answer to life, the universe ...and Your problems - May 18, 2011
  • Achieving 'five-9s' reliability in IP-based communications networks - May 07, 2010
    99_999% image.PNG
  • Serving the needs of critical communications systems - Apr 15, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Dealing with RTP loss

    Copyright Voice of IP

    ]]>     Emergency communications Gateways ESInet NENA Protocols PSAP SIP signal processing distinguish between gateway between failure esinet Wed, 14 Sep 2011 10:11:37 -0500 2011-09-14T10:11:37-05:00     New high density Prosody X PCIe media processing board hits the sweet spot for developers http://blog.tmcnet.com/voice-of-ip/2011/09/new_high_density_prosody_x_pcie_media_processing_board_hits_the_sweet_spot_for_developers.html 47442@http://blog.tmcnet.com/voice-of-ip/ Vanilla cupcake topped with strawberry ganache www.thesweetkitchen.co.ukOur clever engineers have done it again – you’ve now got an even higher density, media processing board with which to play. The new PCIe board joins the Prosody X family of DSP-based boards that are used extensively in multimodal communications systems.

    We could have just taken the existing 4-trunk Prosody X PCIe board and added further trunks and DSPs. Instead we took note of customer feedback and went the extra mile to further improve the original design. 

    The result is a board with vastly increased channel capacities, giving our developer customers the components needed to readily craft large scale systems at a very cost-effective price-per-channel. Whilst many DSP boards top out at 240 channels, the new 8-port Prosody X PCIe board can support up to 720 channels.

    Why such a difference?

    Traditionally, DSP media processing board systems were constrained by their architecture, which was designed primarily to support TDM traffic. With 8 trunks and 30 channels per trunk (for an E1 TDM link) you achieve the 240 channels. Aculab’s ability to support much greater channel counts is due to the IP architecture inherent in the design of the Prosody X board.

    Prosody X – a board designed for the old (TDM) and the new (VoIP) way

    Prosody_X_PCIe_architecture.png

    Figure 1 - Prosody X architecture

    From the diagram above, it can be seen that the Prosody-X board is truly IP-centric, and the entire architecture centres around the Ethernet switch.  The TDM part of the circuitry is the legacy element, and is only used if there is a need to move media off to a legacy infrastructure.  The Prosody X board itself appears to the host server as a NIC, and command and control traffic can arrive at the card, either from the local host, or remotely, via the external Ethernet interfaces.

    Gigabit Ethernet connectivity

    One of the main areas of improvement with the new board was the addition of Gigabit Ethernet connectivity as an option. Earlier PCI and PCIe Prosody X boards were fitted with dual Fast Ethernet interfaces as this was appropriate for the channel capacities possible. Gigabit Ethernet was available only on the cPCI form factor Prosody X boards that, with up to 8 DSPs and 16 E1/T1 trunks, can exploit the bandwidth offered by such an interface.

    To meet market demands, our team of engineers investigated how the board design could be optimised, and determined that they could open up the possibility for the board to support much higher RTP traffic channel counts. When the time came to test the hardware, the theoretical analyses were proven to be correct. A sample of the achievable channel counts are shown in Figure 2 below.

    New-8-trunk-Prosody-X-channel-counts-table.gif
    Figure 2 - sample of channel counts achievable with the new Prosody X board

    As communications platforms increasingly become more IP-traffic centric, so the importance of communications hardware, such as Prosody X, that is highly efficient in dealing with VoIP, gains in importance. 

    In conclusion, if you are looking for a way to build cost-effective, medium or large scale IVR, call-centre, fax server, conferencing server or similar enterprise/telco platforms then you should check out what Aculab and Prosody X can offer. You will be pleasantly surprised.

    To find out more, visit the new 8 trunk Prosody X PCIe board page.

    Look out for part 2 of this blog series on the design of the Prosody X board that will describe further advantages of the IP-centric design.


    Andrew Nicholson


    ]]> Tags: Related tags: , , , , ,
    , , ,
    Related Entries TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: New high density Prosody X PCIe media processing board hits the sweet spot for developers

    Copyright Voice of IP

    ]]>     Media Processing VoIP DSP PCIe Media Processing channel counts media processing processing board gigabit ethernet board support prosody Mon, 12 Sep 2011 10:51:58 -0500 2011-09-12T10:51:58-05:00     Who owns the cloud? http://blog.tmcnet.com/voice-of-ip/2011/09/who_owns_the_cloud.html 47392@http://blog.tmcnet.com/voice-of-ip/ A previous blog post introduced the idea that services (IaaS, PaaS and CaaS) can be deployed in three different types of cloud - private, public or hybrid (there are more variations out there, but those are the key ones for you to consider at this early stage).  Which is the best option for you, really depends on what you’re looking to achieve.  It may be useful to think about your top priorities, for example, ‘risk aversion’ or ‘cost reduction’?
    It’s virtually your choice
    What’s the key factor that sets cloud categories apart? For ease of illustration I shall focus on the provision of IaaS, and it really all boils down to server type.  That’s not a question of whether it’s Dell or Intel – what we’re talking about is physical machines that are dedicated to you and that you can see or go visit, if you wanted to or virtual ones that you can use, but must share with others and couldn’t readily visit, even if you wanted to, because you’d have no idea where they’re located.
    So with that in mind, let’s take a look at each cloud model, the server type used and the headline pros and cons of each.
    • Private cloud – you purchase a dedicated, physical server for your sole use.  You nominate how much capacity or how many servers you need in advance, which you then provision and set aside for you current and future needs. 
      • Pros – shared overheads; ‘ring fenced’ servers
      • Cons – inflexible; likely to pay for unused capacity and resources
    • Public cloud – you purchase access to virtual servers on a capacity/usage basis.  You share server resources and use and pay for what you need, when you need it.
      • Pros – Shared overheads; capacity on demand
      • Cons – no control of resources used, where they are located or any co-habiting applications
    • Hybrid cloud – you purchase a mix of dedicated physical servers, for applications/data that require a high leve’ of security and virtual servers for ‘lower risk’ activity or usage peaks
      • Pros – tailored mix of dedicated and virtual servers to suit your capacity and security requirements
      • Cons – May still result in unused, but nevertheless paid for, resource
    Cloud types.jpg
    Private cloud vs premise-based private cloud
    If you run a quick search on private, public and hybrid clouds, you will certainly find a lot of material.  You will also find what may seem conflicting or at the very least confusing definitions, what is meant by a ‘private’ cloud being a good example.  The key point to remember or to query is whether a private cloud in the IaaS sense is being described or a private cloud that is still premise-based equipment but which adopts ‘over-the-Internet’ architectures.  Depending on what is being described will affect the strength/balance of the benefits presented i.e. there is a big difference in the cost of running your own private cloud and using resources in an IaaS provider’s private cloud.

    What is a virtual server?
    You may be wondering what is meant by a virtual server. Essentially, the term points to the technology or processes that have paved the way for cloud computing – virtualisation of computer resources.  Virtualisation presents the ability for multiple, simultaneously executing applications and indeed, multiple users, to run on or make use of a single machine, through partitioning its capacity. There are a few key points to lay on the table, about which you can learn more – and their related benefits in the next blog.

    For further information and an interesting discussion of cloud types, you may wish to take a peek at the following.

    Insight into the private to public migration strategy http://news.idg.no/cw/art.cfm?id=347D6243-1A64-67EA-E42E7EE0D7A2FDD4

    Aculab Cloud lets you keep your application and data out of the cloud – have a look at Aculab Cloud’s architecture.  It shows that there is flexibility in how you wish to migrate to cloud.
    Faye McClenahan
    Aculab Blogger
    ]]> Tags: Related tags: , , , , ,

    Related Entries
  • What do you need to run a cloud-based telephony application? - Jan 26, 2012
    Traditional_vs_cloud_based_deployments.png
  • Chapter 2: Introduction to Cloud Telephony - What is a Cloud Telephony PaaS? - Oct 12, 2011
    Telephony_paas2.jpg
  • Why shouldn't you move to the cloud? - Sep 01, 2011
  • "Hey, you, get on to my cloud." - Feb 04, 2011
  • The Aculab Cloud - Feb 03, 2011
    Aculab_Cloud_small.png
  • Aculab moves to the cloud at ITExpo - Jan 27, 2011
    Banner_cloud_590px.png
  • Communications technology predictions for 2011 - Dec 21, 2010
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • Voices in the clouds - Nov 30, 2010
    voices_in_the_clouds.png
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Who owns the cloud?

    Copyright Voice of IP

    ]]>     Cloud computing Cloud computing private cloud premise based cloud computing virtual servers private public cloud Thu, 08 Sep 2011 10:16:28 -0500 2011-09-08T10:16:28-05:00     SIP call recovery in gateways http://blog.tmcnet.com/voice-of-ip/2011/09/sip_call_recovery_in_gateways.html 47389@http://blog.tmcnet.com/voice-of-ip/ Life is full of truisms; those self-evident truths in statements like not being able to recover your lost youth (despite what plastic surgeons say – or any number of elderly film stars have wished). It’s not as evident that you can’t recover SIP (session initiation protocol) calls when they appear to fail. What happens when you lose an already established SIP call between a gateway and an end point on a VoIP (voice over Internet protocol) network? Can it be recovered? It depends on what you mean by ‘lose’ and ‘recover’.
    Dictionary definitions of recovery suggest many things, from salvage to sports. The latter always gives good value for analogies, don’t you think? How about a recovery stroke in golf; playing from the rough to the fairway (or a bunker to the green) – hands up if you’re familiar with that one.
    Recovery also covers recuperation (as in convalescence) in addition to repossession and retrieval. In disaster planning – getting closer to technology and SIP call recovery – recovery means the steps to be taken to return all operations and systems to their normal status. In electronic commerce – getting closer still – it’s the ability of a system to be restored so that processing can resume and transactions, aborted due to a failure, can be resubmitted.
    Recovery is also the process of regaining possession or control of something that’s been lost; like our SIP call. But has it been lost? Has control over the call been lost? Is it like Dan Quayle saying, “This President is going to lead us out of this recovery.”?
    Here’s the scenario…
    A gateway is used to interconnect emergency calls between a telco’s SS7 (signalling system #7) network and an ESInet (that’s an emergency services Internet according to the National Emergency Number Association – NENA) to which are connected SIP-based PSAPs (public safety answering points). Calls are made by users from legacy, wired and wireless networks, via the carrier’s central office switch, and the specialised gateway directs them to SIP-based location and routing elements in the ESInet so that the calls can be directed to the appropriate PSAP. With an established call in progress, the SS7-to-SIP gateway is in the middle, and a caller is talking to a PSAP call taker.
    In our hypothetical setting, sometime during the call, the RTP (real-time protocol) voice media gets interrupted – for some reason (it doesn’t matter what). Is the call lost; has either the gateway or the SIP end point lost control over the call; can it be recovered?
    SIP-call-recovery
    The call is only lost if one party hangs up. The call taker will not hang up and NENA’s next generation, i3 specification mandates that the SIP-based equipment, receiving and onwards routing the call from the gateway, should not force the call to stop. The caller is likely to hang up if (s)he thinks there’s nobody listening at the other end, but that will happen only after a time measured in seconds and a few, panicky attempts at “Hello! Hello! Are you still there?”
    To avoid the caller hanging up and exacerbating an already fraught situation by forcing a redial, the gateway has to take responsibility. Its task is to deal with the loss of RTP, between it and the other SIP end point, within milliseconds. It’s important for the gateway to play its part before the expiry of time out #1 (that’s ‘caller time out’ to you). It’s not acceptable for the gateway to wait until the caller hangs up – after all, nobody wants the caller to suffer the ultimate time out, because (s)he wasn’t able to reconnect. It’s vital to ensure connection to the caller is maintained.
    But at this precise point, the call hasn’t been lost. It hasn’t failed, nor has it been aborted and – importantly, the gateway is still in control of the call; both the SS7 leg and the SIP leg. Crucially, the outgoing SIP call monitoring functionality in the gateway has detected that the RTP stream received from the remote SIP end point, has ceased. The onus is on the gateway to automatically ‘recover’ the call by releasing the failed SIP call leg and establishing a replacement call to an alternative SIP application server. Needless to say, the time that must elapse without receiving an RTP packet from the remote end, before call recovery is invoked, is configurable in the gateway.
    In a well-engineered implementation, the IP-SR (IP-based selective router) or ACD (automatic call distribution) equipment receiving SIP calls from the gateway will have multiple elements. That will be for reasons of both redundancy and scalability (i.e., capacity). Those additional servers present the gateway with one (or more) ‘secondary’ SIP servers to which to direct the ‘recovery’ call. Using the original call attributes, a SIP header in the INVITE (it’s not a RE-INVITE) enables the alternative server to identify both calls and be able to route the ‘recovery’ call back to the original call taker – within time out #1.
    If there is more than one alternative SIP server, the gateway is able – a bit like Robert the Bruce and his mythical spider – to try and retry again until it succeeds with the ‘recovery’ call. If we overturned and misappropriated Dollo’s Law – in defiance of nature – we’d say the gateway was able to automatically retrieve and return (restore or re-establish) our SIP call to its previous status. That may not be as good as recovering lost youth, but in terms of preserving the quality of life, it’s infinitely preferable and, unlike some plastic surgery – it’s affordable.
    Enhanced by Zemanta
    ]]> Tags: , , , , , , Related tags: , , , , ,

    Related Entries
  • Dealing with RTP loss - Sep 14, 2011
  • Failover or failsafe? - Jun 18, 2010
  • Why gateways are 'how to' answer to life, the universe ...and Your problems - May 18, 2011
  • Serving the needs of critical communications systems - Apr 15, 2010
  • Why an IP-centric telephony board is the best choice when building highly scalable or resilient solutions - Sep 30, 2011
    Distributed_voice-based_solutions_architecture.jpg
  • Convergence of the old and the new - Mar 23, 2011
    CI_logo_website.png
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • Don't turn a deaf ear to Orange! - Sep 02, 2010
    Orange Logo.png
  • A crowd of daffodils and hosted clouds - Aug 27, 2010
    IMG_6609_crop_sml.png
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: SIP call recovery in gateways

    Copyright Voice of IP

    ]]>     Emergency communications Gateways Gateway NENA PSAP Session Initiation Protocol SIP Voice over IP VoIP getting closer equipment receiving gateway recovery caller calls Fri, 02 Sep 2011 11:08:18 -0500 2011-09-02T11:08:18-05:00     Why shouldn't you move to the cloud? http://blog.tmcnet.com/voice-of-ip/2011/09/why_you_shouldnt_move_to_the_cloud.html 47402@http://blog.tmcnet.com/voice-of-ip/ This question, albeit it’s more of a statement seeking endorsement, was recently raised on LinkedIn and it generated a variety of responses relating to security, ease of use, and flexibility, to name but a few. I couldn’t resist the temptation to respond and counter some of those ‘issues’.

    Security – any computer connected to the Internet is at risk from hackers, whether it is in the cloud or in a private data centre. Would it be true to say that an SME, with necessarily limited resources, is able to better secure its data than say, Amazon?

    In addition, who says everything needs to be in the cloud? Adopting a cloud computing strategy isn’t an ‘all or nothing’ decision. With Aculab Cloud, for example, data can remain within a data centre or on premise, whilst applications that need to access such data can be based in the cloud. That’s the whole principle behind the different cloud types – private, public or hybrid.

    Ease of use – I find this a curious reason not to move to the cloud. In my experience, SaaS solutions are all the more easy to use because of the accessibility they bring. You can log on, access, analyse, modify or configure them from anywhere, via any device.

    Flexibility – It seems a bit harsh to blame the cloud for the inflexibility of a service. I can think of many applications/services that are inflexible, because that’s how they were designed to be.

    I think that anyone considering a move to the cloud, needs to carefully consider their motivations and objectives for doing so, and to question what data and workflows they and their customers will feel happy placing in the cloud.  Most importantly, select a vendor that can accommodate your cloud migration strategy, now and in the future. 

    Enhanced by ZemantaFaye McClenahan
    ]]> Tags: , , Related tags:

    Related Entries
  • Chapter 2: Introduction to Cloud Telephony - What is a Cloud Telephony PaaS? - Oct 12, 2011
    Telephony_paas2.jpg
  • A crowd of daffodils and hosted clouds - Aug 27, 2010
    IMG_6609_crop_sml.png
  • What do you need to run a cloud-based telephony application? - Jan 26, 2012
    Traditional_vs_cloud_based_deployments.png
  • Who owns the cloud? - Sep 08, 2011
    Cloud types.jpg
  • The impact of cloud computing on the service provider market - May 13, 2011
  • "Hey, you, get on to my cloud." - Feb 04, 2011
  • The Aculab Cloud - Feb 03, 2011
    Aculab_Cloud_small.png
  • Aculab moves to the cloud at ITExpo - Jan 27, 2011
    Banner_cloud_590px.png
  • Communications technology predictions for 2011 - Dec 21, 2010
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Why shouldn't you move to the cloud?

    Copyright Voice of IP

    ]]>     Cloud computing Cloud computing SaaS Software as a service cloud Thu, 01 Sep 2011 06:31:10 -0500 2011-09-01T06:31:10-05:00     Microsoft and Skype http://blog.tmcnet.com/voice-of-ip/2011/08/microsoft_and_skype.html 47388@http://blog.tmcnet.com/voice-of-ip/ On the 10th of May it was announced that Microsoft had agreed a deal to acquire Skype for US$8.5 billion. Since then there has been much industry chatter about ‘why’ and ‘what’ this means for the industry. For me the only question mark is over how much they paid.
    Microsoft has been moving into telephony for a number of years now. It was a natural progression for its business offering to include telephony, voice and video, in the evolution of work-based collaboration and in fact voice and video have been available as part of MSN Messenger for many years. This highlights an area of synergy between Microsoft and Skype; Microsoft, with MSN Messenger, allowed people to communicate over the Internet for free, exactly the area of the market that has proved to be so successful for Skype.
    So, why Skype? Well, Skype is the world’s only truly global telephony service provider. It can offer it’s users connectivity to the PSTN, allowing calls to any phone/mobile phone in the world whilst offering the new generation services such as instant messaging, presence and video calls, to its on-net customers. When you start to look at the services Skype can offer it’s customers  - yes some are free, but many do have a cost associated with them  - then you start to appreciate how Microsoft can exploit this with it’s own products and not just for the home user but for business as well.
    Microsoft could utilise the Skype network to offer inter-company communications beyond the enterprise boundaries, not only reducing call costs compared to the PSTN but also making services such as voice and video conferencing easily available.  The fact is that there are a number of services or applications that could be offered as part of a business service, whether that is to the business user in general or as part of an overall Microsoft solution based around its Lync products.
    I know that there will be many out there who will put forward the lack of quality of service as an issue, but experience seems to show that this isn’t really a problem and that call quality is acceptable. In fact compared to calls on mobile phones the quality is actually quite good. Speaking of mobile communications, there is of course the tie up between Microsoft and Nokia to consider and how Skype services could be used in applications for both the home and business user. Mobile communications have become so ubiquitous in our lives that the old fashioned ‘land line’ is in danger of becoming obsolete (more of this another time) and that this may go some way to explain why voice quality is far less of an issue; we’ve just got used to ‘terrible’ calls.
    Strategically this a very good move by Microsoft and one that could make them the major player in the telecoms market in the near future. The market itself could be on the cusp of major changes; not so much in the services we use, but in the way those services are provided. As I said at the beginning the only issue, well 8.5 billion issues, is the amount that was paid and how long it’s going to take to get a return on that investment. My guess is that Microsoft is in this for the long haul.

    Andy Dakin
    June 2011
    Enhanced by Zemanta
    ]]> Tags: , , , , Related tags: , , , , ,

    Related Entries
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • The evolutional path of media processing systems - Feb 10, 2012
    evolution.jpg
  • Why an IP-centric telephony board is the best choice when building highly scalable or resilient solutions - Sep 30, 2011
    Distributed_voice-based_solutions_architecture.jpg
  • HD Voice - it's all about connecting up the disparate islands - Jun 15, 2011
  • Convergence of the old and the new - Mar 23, 2011
    CI_logo_website.png
  • Meet the Aculab team for ITExpo East 2011 - Feb 01, 2011
    John_K_small.png
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
  • Voices in the clouds - Nov 30, 2010
    voices_in_the_clouds.png
  • Military manoeuvres - Oct 21, 2010
    Chinook helicopter
  • Fax server developers looking for the most cost effective development platform should see what Aculab has to offer - Oct 19, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Microsoft and Skype

    Copyright Voice of IP

    ]]>     Convergence Aculab Microsoft Skype UC Unified Communications voice video mobile communications between microsoft microsoft skype microsoft skype Wed, 31 Aug 2011 11:48:27 -0500 2011-08-31T11:48:27-05:00     HD Voice - it's all about connecting up the disparate islands http://blog.tmcnet.com/voice-of-ip/2011/06/hd_voice_draft.html 46911@http://blog.tmcnet.com/voice-of-ip/ Oresund Bridge from Denmark to Sweden. On the ...

    Oresund Bridge, image via Wikipedia


























    This weeks announcement[1] by Orange that it plans to roll out mobile HD Voice to several more countries throughout Europe, and from UK operator Three that they will roll out HD Voice capability to ‘most’ phones by the autumn is good news for the spread of HD Voice, but Orange are missing a trick.

    Read down to the bottom of the Orange press release and you come to the part about hooking up its HD Voice capable mobile networks with its own broadband fixed network service that currently has approximately 800,000 subscribers. Orange is not planning to enable a customer who might have its wideband service on their home network to talk to someone (possibly a member of the same family) in HD Voice quality on a mobile phone until 2012 or 2013!

    If HD Voice is to succeed in a big way, then you have to create a system that allows you (with a HD Voice capable device) to call another person (with an equally capable device) and not have to rely on that person being on the same network as you to guarantee the ability for the call to be setup with the best quality.
    If disparate islands of HD Voice capability are developed in isolation, then the technology will never achieve its potential to revolutionise the voice communications landscape. What is needed is a concerted effort, from Orange and others, to create the bridges between these islands. If we can build road bridges between countries (I am referring here to the Oresund bridge opened in 2000, to connect Copenhagen in Denmark to Malmo in Sweden, a distance of 4.8 miles) to facilitate better communications and trade links, then surely we can create a global HD Voice telecommunications system by focussing some of the effort on the links between different operators and network types, fixed and mobile, and transcoding between different codec types that are used in these networks.

    However, Orange doesn’t need to wait a year or more before they connect up their HD Voice island with others – the technology to facilitate the island-interconnection for Orange to hook up its fixed HD Voice network to its mobile HD voice network is all currently available. All you need is a transcoding server with support for the fixed and mobile HD Voice codecs (G.722 and G.722.2), and some work perhaps on the billing/OSS, and you have a solution. If you don’t know where to go for such technology, you could do worse than to start with Aculab’s media processing technology, Prosody X or Prosody S, which would build into a very capable HD Voice transcoding engine.

    Andrew Nicholson

    [1] Orange opens up access to High Definition Voice for its customers

    ]]> Tags: , , , , Related tags: , , , , ,

    Related Entries
  • Don't turn a deaf ear to Orange! - Sep 02, 2010
    Orange Logo.png
  • HD Voice - how much bandwidth do you need? - Mar 30, 2010
    wideband-fullband_bandwidth.png
  • The evolutional path of media processing systems - Feb 10, 2012
    evolution.jpg
  • Why an IP-centric telephony board is the best choice when building highly scalable or resilient solutions - Sep 30, 2011
    Distributed_voice-based_solutions_architecture.jpg
  • Microsoft and Skype - Aug 31, 2011
  • Convergence of the old and the new - Mar 23, 2011
    CI_logo_website.png
  • Meet the Aculab team for ITExpo East 2011 - Feb 01, 2011
    John_K_small.png
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • Voices in the clouds - Nov 30, 2010
    voices_in_the_clouds.png
  • Military manoeuvres - Oct 21, 2010
    Chinook helicopter
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: HD Voice - it's all about connecting up the disparate islands

    Copyright Voice of IP

    ]]>     HD Voice VoIP Aculab HD Voice Orange transcoding Wideband audio fixed mobile oresund bridge between different voice capable voice network voice Wed, 15 Jun 2011 06:33:41 -0500 2011-06-15T06:33:41-05:00     Why gateways are 'how to' answer to life, the universe ...and Your problems http://blog.tmcnet.com/voice-of-ip/2011/05/why_gateways_are_how_to_answer_to_life_the_universe_and_your_problems.html 46711@http://blog.tmcnet.com/voice-of-ip/
    [By the way; that’s a gateway as distinct from a router, Proxy server, or some form of gatekeeper or firewall function at an entry/exit point to the network.]

    Sure, gateways aren’t wicked or malevolent – like vampires. Come to think of it, though, if it wasn’t for vampires, neither Peter Cushing nor Christopher Lee, not to mention Buffy (who polished off many a vampire), would’ve had much of a career. You’d probably think they’d be inclined to say, “Evil is good!”

    So gateways are a necessary evil, which means they’re a good thing. Let’s face it, nobody buys a gateway, because they want to. Gateways are purchased because they are needed. Gateways are the vampire slayers of the netherworld of communications. Gateways are purchased, because somebody, somewhere, in their own particular universe, has a problem to solve – because they are necessary. That’s a truism (close to being a fact). But, what’s the problem?

    Here’s an eccentric example. A telephone service is implemented using two tin cans and a length of string, but the string breaks; it’s been frayed or worn and cut or torn, and communication has been lost. Think of the gateway as the knot in the string that fixes the problem. If that analogy doesn’t quite work, think of the tin cans being in the hands of a call centre agent in say, Glasgow, and a customer in London – a magic gateway then helps them communicate (as neither is guaranteed to be speaking the same language, “Ye ken whit I mean?”).

    And, if that still doesn’t do it for you, think of the call centre being served by an Avaya Communications Manager running SIP and the caller being on the other end of a PBX in a DPNSS network. In that scenario, the gateway solves the problem of the two parties not being able to interconnect. In fact, that’s tantamount to being a definition of a gateway.

    A gateway is an appliance that is placed between two networks (or a piece of equipment and a network) that use different base protocols in order to enable communication between them by converting data and signalling from one format to another – problem solved!

    In one way or another, a gateway is an internetworking device capable of joining together two networks. In a sense, by the above definition, a gateway appears at the edge of a network. However, once it’s installed, the two networks behave as one and the gateway should be no more intrusive than the knot in the string.

    One example of a gateway solving real world, business problems was where a certain user’s customer premise equipment (CPE), running one particular protocol, needed to connect to a network using a fundamentally different protocol.

    [For those wishing to know, the CPE was running the legacy T1 robbed bit protocol – a multi-frequency (MF) tone-based signalling protocol – and the network, to which it needed to connect, was operating a Q.931-based, primary rate, ISDN protocol, which in that particular case, was ETS 300 (aka DSS1 or Euro ISDN).]

    The problem was compounded by the need for calls to be directed towards specific devices sitting behind the CPE, which could be identified only by means of ISDN sub-address data. It wouldn’t have been much of a problem if the CPE had been an ISDN-based PABX, but as so often inconveniently happens, it wasn’t.
    The ‘how to’ answer for the systems integrator needing to design a solution for the end user was not to attempt to use an expensive PBX. Nor was it to redesign or adapt its own technology by adding some proprietary hardware and software; all of which would’ve consumed valuable time and resource that it didn’t have to spare. The answer was to use a gateway (in this case, Aculab’s GroomerII), which solved the two-tier problem; not only converting between the two protocols, which was a given, but also adapting the incoming call data to manipulate the outgoing call in the desired manner.

    From a business perspective, the added cost of the gateway was by far the lesser of all alternative ‘evils’ and, in point of fact, the operating cost benefits of the successful outcome outstripped any concerns over the marginal, additional capital cost involved.

    There are many other real world, problem solving examples involving vampire-slaying gateways. Just think of the gateway as the ‘knot in the string’ – a string of garlic if you like.

    Blog by Ian Colville]]> Tags: , , Related tags: , , , , ,

    Related Entries
  • SIP call recovery in gateways - Sep 02, 2011
    SIP-call-recovery
  • Failover or failsafe? - Jun 18, 2010
  • Dealing with RTP loss - Sep 14, 2011
  • Cloud is the new hosted in the adverse diverse universe - Dec 10, 2010
  • We're doomed! - Dec 03, 2010
    Dads Army Frazier - doomed.png
  • Don't turn a deaf ear to Orange! - Sep 02, 2010
    Orange Logo.png
  • A crowd of daffodils and hosted clouds - Aug 27, 2010
    IMG_6609_crop_sml.png
  • Heading in both directions at once - Aug 18, 2010
  • Achieving 'five-9s' reliability in IP-based communications networks - May 07, 2010
    99_999% image.PNG
  • Serving the needs of critical communications systems - Apr 15, 2010
    • TrackBacks | Comments | Tag with del.icio.us | Voice of IP Home | Permalink: Why gateways are 'how to' answer to life, the universe ...and Your problems

    Copyright Voice of IP

    ]]>     Gateways SIP TDM VoIP think gateway purchased because needed connect gateways purchased gateway problem Wed, 18 May 2011 06:32:11 -0500 2011-05-18T06:32:11-05:00