Communications technology predictions for 2011

The end of the year is always a traditional time for looking back on the previous 12 months – and looking forward to try to prepare for what’s to come. Rather than just put down my ideas, I captured some of the thoughts from Aculab’s global team to see what they thought would be the technical trends to look out for. So, without further ado, here are Aculab’s top three predictions for communications technology in 2011:-

Cloud-based communications will continue to gain in importance

Cloud computing will continue to shake up the established way of doing things, both for operators and equipment vendors such as ourselves, throughout 2011.

Cloud communications – the use of someone else’s server hardware to host your platform – sounds ideal as it eliminates CAPEX and reduces OPEX, but brings with it new challenges for time sensitive voice communications.

Call centre servers are perhaps an ideal candidate for being migrated to the cloud. With flexible server capacity on offer, for example Amazon’s EC2 platform, the processing power for a call centre can be adjusted according to demand ‘on the fly’, opening up possibilities for provision of campaign specific call centres without huge OPEX investments. Several call centre vendors are already providing cloud or virtual call centres, an example being NewVoiceMedia in the UK. Watch for other call centre platform vendors moving into this space – will they survive if they don’t take the leap?

Aculab is focussed on harnessing all the capability of our hardware and software-based media processing platforms to meet the needs of the cloud environment as it moves towards the mainstream.

Video communications will continue to expand predominantly as one-way video applications
I recently bought my son an iPod Touch for his birthday – the new one with FaceTime video calling capability. He has now had it a week or so, but so far has not even tried out FaceTime. Why? – because he doesn’t know anyone else with the same device to make a FaceTime call to! This is just one example of the problem with video calling today – technically possible, but still too niche and lacking standardisation. What a mess we would be in with voice calling if, for example, you could call only the people who had the same brand of phone as you – not too bad if you had a Nokia of course, since they still dominate the overall worldwide handset market with a 32% market share (based on 3Q10 figure analysis), but not so good for anyone else. Thankfully, the world has standardised on the PSTN and a common numbering scheme that all phones – fixed and mobile – have to use. For interconnectivity between VoIP phones, we need co-operation between SIP providers and SIP trunking – but that is another issue…

Another view is that perhaps video calling has been left behind, and the new generation doesn’t need or want it. A common opinion among the younger crowd is ‘why call when I can text, IM chat, post to facebook or send a tweet?’ (I am sure if you have kids you know what I mean). If they don’t see the need to even make a voice call, what chance does a video call service have? That said, perhaps the new breed of tablet devices such as the iPad that offers a good sized screen ideal for video calls will change things – but then again, the iPad is not a mobile – it is a portable computer, more likely to see use at home. The smartphone with its 3.5” or 4” touchscreen is the device most people would carry around all the time – make video calling over WiFi AND 3G reliable and simple to use, then perhaps it will take off. Just don’t hold your breath…

On the other hand, devices such as smartphones are excellent for content consumption, including one-way video. Expect to see a proliferation of services using one-way video in addition to voice capability – much simpler to implement, and actually something end-users would value.

Use of integrated voice and messaging platforms expands
As alluded to above, it seems that what people want is integration of all types of communication – voice, mobile SMS, IM chat, facebook interactions, tweets and video (one-way) – all on one, preferably mobile, platform. This was a common theme mentioned by several Aculab team members in both the UK and the US.

Everything is going mobile, and as smartphones gain traction and consumers migrate from their ‘dumbphones’, then we will see more and more applications migrate from the desktop/laptop computer to a mobile device. With consumers using the single device for all forms of interaction, we will see a growth in mobile advertising. Broadcast of advertisements via text and multimedia messages will be huge in the next few years. I can see the day where you get phone service credits (i.e. you pay less money for service on a phone if anything at all) based on the ads you receive, view or act on. The ability to track this and broadcast the messages in whatever format (SMS, MMS, etcetera) is required offers huge potential to a product such as Aculab’s AMS Server.

Personal unified messaging systems (i.e. same phone number receives comms for multiple phones such as home phone, mobile and office) will be standard, not just a hobbiest item like Google Voice.

The Facebook/Skype integration will be one to watch – the biggest social media platform integrated with the biggest free VoIP service. Can they do more with Facebook than they ever did with the eBay integration?

It looks to be an interesting year coming up.

Wishing all our readers a Happy Christmas – after which the Aculab team will be fully refreshed and ready to take on the challenge of continuing to develop world-class hardware and software to support these new services.

Andrew

About me
Andrew Nicholson is a Product Manager at Aculab responsible for the Prosody X and Prosody S media processing products. You can contact me here. Alternatively, follow Aculab using our Twitter account, Aculab.

Cloud is the new hosted in the adverse diverse universe

If there was always one, single, universal answer, we’d not have Pepsi, Coca-Cola and IRN-BRU; there would not be around 20 diverse, major religions or belief systems in the world; Android, iOS 4, Symbian OS and Windows Phone 7 would all be superseded by ‘Universal SmartPhone OS 2’, and we’d all dress the same – like the characters in Logan’s Run.

Thankfully, the world is full of heterogeneity and that applies also to the α-diversity in the communications marketplace. Unified communications (UC) does not mean uniform communications and there is a ‘business case for diversity’ beyond that which talks of the composition of the workforce. It’s called competition.

The hype regarding competition in today’s communications marketplace is all about the ‘cloud’ and if we are to believe that, businesses should be falling over themselves to implement UC or their contact centres or Web-telephony, in public or private cloud networks as if that was the solitary answer. The reality is somewhat different and enough to make any self-respecting evangelist utter a simple unitary philippic in exasperation. You can hear them say, “They just don’t get it, do they?”

Enterprises, particularly SME/SMBs, probably see the ‘cloud’ as suggested by these lines from the Pretenders’ song ‘Don’t get me wrong’:

“If I come and go like fashion, I might be great tomorrow, but hopeless yesterday’. On the other hand, ‘it might just be fantastic’. It is going to be fantastic, but if current trends in the UK telecommunications services industry are anything by which to go, it’s going to have to wait for tomorrow – which, never fear, will come.

In the UK, there doesn’t yet seem to have been a landslide in favour of hosted telephony or other applications, such as SaaS or cloud-based applications delivery. Back in 2006, a Dell’Oro Group forecast suggested the total PBX market would be US$7.1 billion annually by 2010. They were right, but recent financial meltdowns are reflected in a current forecast, which points to the global market exceeding US$6 billion in 2014. Its 2008 report looked forward to growth fuelled in large part on increased sales to SME/SMBs and from 2006, apart from ‘extenuating circumstances’, the year after year predictions were for a reasonably steady market. The question is, “Why, at a time when OPEX is favoured more than CAPEX, has there been no avalanche of hosted or cloud-based solutions enveloping the prime target; those very SME/SMBs?”

It’s an interesting question when you consider that other intelligence from ABI Research indicates that enterprises are ramping up their investments in VoIP technologies on both customer premise equipment (CPE) and hosted VoIP. It goes on to say that overall revenue growth is due to brisk competition between CPE vendors and hosted service providers, but it does add that hosted VoIP is a ‘safe investment’, precisely because it offers flexibility at this time of uncertain economic recovery. Its research suggests that hosted IP PBX services should exit 2010 with a 15.3 per cent increase in revenue to US$3.4 billion worldwide, which means that it does have traction. One third of the market is more than a tremor and it brings us closer to a shakedown.  

The market inertia is because of the spenders’ disinclination to change and for there to be more than a slim chance of a mudslide, the tipping point needs to be reached. ‘Cloud’ is the new hosted and if we talk of ‘true cloud’, in addition to simply ‘hosted’, and of solutions being ‘engineered for the cloud’, it will help folks over the edge. Numerically, SME/SMBs constitute the largest proportion of the diverse communications marketplace and, in theory, should benefit most from getting on board the ‘cloud’ bandwagon as it rolls over the rim. But thinking about it, wouldn’t that make them all lemmings?

We're doomed!

“We’re doomed!” said Pte. Fraser in the cult BBC comedy, Dad's Army.

Well, that might be true if you’re concerned about global warming, the exhaustion of finite, carbon resources, the disappearance of tinority* languages like Busuu, the fact that the sun will burn out in around five billion years, or the B’ak’tun Cycle of the Mayans. For the rest of us, life goes on…

Ever since the last notional disaster of Y2K, which might just be a coincidence, we’ve been told that the days of the highly exclusive club of conventional telecommunications operators are numbered. The dismantling of the oligopoly and the resultant consumer freedom from practices that were based on over subscription and bundling were to herald a new dawn and sound the death knell for network providers.

However, the ‘unbundling’ of telecommunications services, despite its impact on the traditional, incumbent operators, hasn’t resulted in too many death throes. Do you know of any major player that has ‘gone to the wall’ in the ten years since VoIP has been lauded as the answer to life, the universe and everything? The major casualty has been, rather than the carriers, the telecommunications equipment manufacturers (TEMs). Look at the changing landscape of the big names and ask yourself what’s happened to the likes of Alcatel, Ericsson, GEC, Lucent, Marconi, Nortel, Philips, Siemens and any others of which you can think. The point is how they have changed.

Words like monolothic and proprietary have often been used to denigrate the traditional industry players, but it was always more so the case that it was the TEMs to which that applied. More particularly, it was the products they offered to which those terms applied and in the illusion that was created, the telcos and network providers suffered by association. After all, they were the ones that bought those products.

The beneficial change that has taken place over the last decade – yes, we’re now in the ‘teenies’ as opposed to the ‘naughties’ – has been the emergence of disruptive technologies such as open source, server virtualisation and cloud network architectures. All of these have benefitted from the bandwagon of IP, upon which you may stack VoIP and IP telephony. However, it does seem a myth that open telecommunications software platforms have more expansive feature sets than their predecessors. How many open source PBXs can offer the equivalent of all forty-nine DPNSS features?

What is true is that subscribers (now, there’s an outdated word if ever there was one) or consumers and business users now have far more than a handful of options. In the UK, there are at least 135 telecommunications operators and resellers, including those offering direct and indirect access, carrier pre-selection, call through (two stage dialling) schemes and VoIP. Interestingly, the total operator reported revenue over the last five years in the UK has remained fairly steady either side of the £40bn per year mark. Instead of showing a marked decline, it has shown a slight increase of five per cent over the period.

Those who attempt to persuade that open platforms have more expansive feature sets are disingenuous. The real issues are applications and services for which features are merely an enabler. The problem we faced five years ago was how to break out beyond simply recreating what was possible in the PSTN and offering hosted IP PBX services. Now, in the age of social media and with a wide array of ‘anything-as-a-service’ sized exactly to your needs available from within cloud networks, the landscape has been altered.

We can see the Tier 1 operators adapting to offer on-demand, pay-per-use, fully customisable, virtualised infrastructure that is designed for application hosting and storage, based on their existing physical network assets. Perhaps the TEMs, an endangered species if ever there was one, need to reinvent themselves as providers of ‘communications applications as a service’. Think unified communications and cloud computing; a marriage made in the heavens (or the void above the exosphere).

Are we doomed? On the contrary, we’re in the midst of the transition to a brave new tomorrow. As Capt. Mainwaring said, “Shut up! Fraser”.

*Note: a ‘tinority’ is smaller than a minority; by an order of magnitude.


About me
Andrew Nicholson is a Product Manager at Aculab responsible for the Prosody X and Prosody S media processing products. Aculab's latest product, AMS Server, sets out to speed and simplify the deployment of voice platforms for on-premise, hosted and cloud services.

Voices in the clouds

Cloud computing is a hot topic currently – but it is a complex subject area with different meanings to different people. In its simplest form, it is a term used for cloud storage/backup services. Others use the term to describe their software-as-a-service (SaaS) offerings – where software applications that would have been run on your own servers are now hosted by a service provider. Finally, and perhaps the most demanding, is CaaS – communications-as-a-service – where a real-time enterprise communications platform is hosted in the cloud.

In the communications technology space that Aculab has been a part of for some 30 years, we are also working towards making the cloud-based communications service a reality. Many thought, perhaps, that it would not be possible to host real-time voice and video communications in the cloud, as they require precise control of network delays, tight jitter tolerances and QoS guarantees. But it is possible, and in fact can work very well.

The science of military communications

I wonder if any of you based in the UK remember the British Telecom television advertisements of the late 1980s featuring ‘Beattie’, played by Maureen Lipman? In the most frequently quoted episode, Beattie’s pride leads her to see only the silver lining in her grandson’s otherwise poor GCSE results. Finding that he passed only pottery and sociology, she declares, “An ology! He gets an ology and he says he's failed. You get an ology - you're a scientist!”




It’s probably fair to say, there will be a few scientists attending the MILCOM show in San Jose at the end of the month. Maybe the organisers should organise a competition to see how many ‘ologies’ you can spot. Going right back to military origins, several ‘ologies’ would be needed to discover the earliest known occurrence of warfare. Between humans that is; not between humans and aliens – for that you just need imagination or a Heinlein book. You could imagine archaeology and geology being used to identify the defensive nature of early settlements. You can surely envisage anthropology and palaeontology being used to study the origins, and the social and cultural development of early warriors.

It’s appealing to think that warfare probably began as the result of a breakdown in communications. After commerce had been established between villages or herding camps, local competition over resources could well have given rise to the earliest conflicts. You can just imagine how it might have transpired; “Now look guys, let’s not be hasty here!” Wouldn’t unravelling those ancient conversations become the science of ‘communicatology’?

Incidentally, the earliest evidence for man having died a violent death due to the aggression of another comes from c. 18,000 BC in the remains of a young man. He was found near the Nile River with several spear points embedded in his upper body. At that time, archaeological and geological evidence suggests that food was scarce, so perhaps he died in a fight over the means of subsistence. The first archaeological record of what could have been a prehistoric battle is to be found at a Mesolithic site, also near the Nile, on the Egypt-Sudan border. That find includes more bodies and arrowheads, clearly indicating the casualties of a battle, which have been determined to be about 13,140 to 14,340 years old.

These days, the sciences involved in communications are largely employed to detect and avoid or prevent conflict arising. If early warning systems fail, it is also deployed to help win the battles and the war. This is evident from the military acronym ‘C4I’ – meaning ‘command, control, communications, computers and intelligence’. Command and control (C2) is about decision-making, and it’s supported by computers and communications; two pervasive enabling technologies that support C2 through intelligence (that’s the ‘I’).

Aculab’s enabling technologies are used extensively in military communications systems, providing many essential functions such as the core media processing capabilities for enhanced voice processor units, and a variety of signalling and media gateways. DSP boards and host media processing (HMP) software can be readily integrated through Aculab’s APIs (high- and low-level APIs are available), enabling the development of a wide range of platforms and systems for military specific applications. That’s why we call it enabling technology – yes, it’s an ‘ology’ and scientifically speaking, you may call it ‘communicatology’. Why don’t you stop by booth 1337 when you’re at MILCOM next week; we’d be pleased to see you.

Military manoeuvres

The announcement this week in the UK of the outcome of the Government’s strategic defence review has placed such matters in sharper focus prior to the MILCOM show in San Jose, CA. at the end of the month. Looking for silver linings to the dark clouds looming over our storm troopers, it’s all in the name.

Conventional forces appear to have taken a massive hit, with various fighter aircraft, warships, tanks and artillery all doomed. The high-profile casualties are the most recognisable names – the Nimrod MRA4 spy-planes and the Harrier jump jets (losing out to the Tornadoes).	Image via Wikipedia
But it’s not all doom and gloom as a round dozen new Chinook helicopters will be ordered. Now, there’s a name with which to conjure.

So perhaps ‘unconventional’ is now the name of the game as the strategy looks to be to switch resources to countering ‘asymmetric threats’ from terrorist or extremist groups, cyber crime and criminal gangs. It seems that the UK will remain able to play a role on the world stage, but its armed forces will be part of a global police force, participating in peacekeeping or humanitarian missions. The RAF might fly support for counter-insurgency and the Army could carry out Special Forces missions against terrorist groups.

As for naming conventions, the acronym ‘MILCOM’ is used for a show that is all about military communications. The old joke is that used to be an oxymoron, but in terms of technology and investment, communications is now right up there at the cutting edge. And in relation to ‘asymmetric threats’ and the notion of a UN-led Gendarmerie, it has to be on the front line.

Looking behind all this talk of cuts and political name calling, surely now there is a need to focus on the development of military communications (MILCOM) solutions. After all, information is power and that’s the name of the game. Strategically, there is more than ever a good argument for naming commercial off the shelf (COTS) building blocks as first choice when looking to construct a given system.

The benefits of a COTS approach is characterised by:

• Reduced risk, because the equipment has been proven commercially
• Reduced development times (even greater if a high-level API is used)
• [Resulting in…] quicker time to market
• The latest technology, because vendors operate in a competitive environment
• Compliance with international standards
• Assured interoperability, interconnectivity, and interworking (Aculab’s ‘3Is’)

Of course, the dilemma with using the COTS approach has been that commercial systems often don’t have exactly the right military-specific feature variants needed. Often, the core enabling technology has to be tweaked (a technical naming convention meaning ‘adapted’) and, therefore, a flexible approach to non-recoverable engineering (NRE) development on the part of the COTS vendor is essential. And, in terms of technology requirements, high channel densities, reliability and flexibility are all essential requirements of technology destined for military applications.

Incidentally, at Aculab we take an open approach to product evolution, where customers can request feature modifications and see that result in a change based on business case evaluation. It’s a refreshing approach, and maybe that agility and willingness will be even more in demand in the post- strategic review product development theatre.

Fax server developers looking for the most cost effective development platform should see what Aculab has to offer

Aculab may be better known for voice applications where our award winning hardware and software is used as the core technology to power contact centre IVR systems, voice conferencing servers, etcetera, but perhaps less well known is the fact that those very same media processing hardware boards (Prosody X) and host media processing software (Prosody S) also support many other functionalities:

• Modem protocol support (wide-ranging support for ITU-T V series modem protocols) and V.150.1 Modem over IP (MoIP)
• Video communications (RTP-based video sessions, H.263 and H.264 packetisation)
• Full SIP stack, unique SIP redundancy capability, and H.323 call control
• Full range of fax capabilities (T.30, T.38 up to V.34 speed, G.711 fax pass-through)

This post describes the fax solutions available from Aculab.

Developing video communications applications that will sell

People of a certain age, including myself, grew up watching sci-fi shows such as Star Trek and even earlier, Flash Gordon (remember that?) – and the idea that a portable ‘communicator’ could be carried or worn to enable communications back to base was certainly a space-age idea. The communication would be not just voice, but often video also from the distant crew member. Here we are a few decades later, and this type of communication is now possible – amazing! However, whilst we have all seized the opportunity to have a personal voice communicator with us at all times, how many have tried out the facilities now becoming more widespread of video communication?



What, then, should enterprises and operators do with video technologies to make them sell?

Five types of developer - which group are you in?

VoIP or SIP application developers can be categorised by the clothes they wear, the bicycles they ride or the approach they take to programming. This post is about the latter. Which grouping do you belong to when it comes to writing VoIP, IP telephony or SIP-based applications?

Regardless of the purpose of your application, whether it be a straightforward, IVR/auto-attendant ‘front-end’ or a complex, unified communications application for a sophisticated contact centre environment, you can approach its development from a number of different angles. There are many competing methods for developing software. Here are five you can try:

1.    The traditional method
Developers taking this approach are becoming increasingly rare and as a consequence, their skills can be much in demand. They could be described as the ‘shorts and sandals’ brigade. Thankfully, they are far from extinct and their expertise makes them consistently sought after. Their value stems from having gained a fundamental knowledge of the intricacies of telephony and protocols, and an ability to use low-level programming languages, such as C, to best advantage.

The products they use are likely to be those from the traditional ‘voice board’ manufacturers, who provide professionally documented application programming interfaces (APIs) in C or C++. They appreciate the level of control that can be exerted over the behaviour of an application via a low-level API. Vendors typically provide a portfolio of DSP boards or host media processing (HMP) software with proprietary APIs.

2.    Application generators

The conventional user of the ‘App Gen’ has been the enterprise IT Services Manager. These are individuals with loosened ties and a permanently worried expression. Their broad skill sets make them invaluable to any organisation, however, they may occasionally suffer from the ‘jack-of-all-trades’ syndrome. What they often need is the ability to cobble together rapidly an IVR application for that new call centre.

Typically, the kinds of tools they can deploy are entrenched in the development environment of Microsoft .NET technologies. These are extremely useful and easy to adopt as they do not need an extensive learning curve. That is because the telephony functions – mainly restricted to basic IVR capabilities – are represented by a library of components. The ‘developer’ simply drags ‘n’ drops icons (or modules) into a GUI workspace to create the desired application. Integration with a third party DSP voice board or, increasingly, HMP software is needed.

3.    VXML/CCXML approach
This is the realm of sophisticated users of service delivery platforms, which can be hosted on behalf of an enterprise or installed in its contact centre. VoiceXML and CCXML scripts are served up from a Web server and the great benefit is that new call flows and IVR interactions can be produced by any sharply dressed end user. That can be done very cost-effectively and in real time, without needing to engage an expensive, third party developer.

Of course, VoiceXML brings with it the great promise of open standards. However, whilst scripts written to conform to the specification should run on any VoiceXML interpreter or ‘browser’, a telephony engine or media server is needed. That underlying hardware or software must have been integrated with the vendor’s interpreter. Usefully, integrations are available across the spectrum of open source and commercial board and HMP software providers.

4.    Telephony by Web page
There is a new breed of telephony application developer who is a kind of cross-over between geek and entrepreneur. These folks are looking to shake up the landscape and demand that making a voice call be as simple as HTML. This kind of independent developer treats the application as a Web page and looks to leverage their existing skill set in languages such as PHP and Java.

In the majority of cases, they depend upon a hosted or cloud-based telephony platform that is accessible to the user’s Web application, which is registered through its URL with the service provider. A great attraction of this type of service is that it is often free to try online via a ‘sandbox’, when all the developer needs is to register for an account. Fees are charged for real, deployed applications and increase when other functions, such as SMS and speech recognition, are added. The entrepreneurial developer pays the provider a monthly $ fee and/or a ¢ per minute rate, and rakes in the marked-up fees when the application (hopefully) becomes popular with the masses.

5.    New era developer tools
This approach is for those developers, whether sandaled or suited, who are crafting real-world applications and need to add telephony functionality to their platforms. They could be from the Microsoft .NET / Visual Studio / C# or the open source, Linux and Python community. A common theme is that they will be using such familiar, general purpose programming languages for coding. They will be seeking development tool kits with APIs written in those very same, high-level languages so they can ‘dive straight in’ and immediately begin writing the application in their preferred language.

The availability of abstracted, high-level APIs means that an ‘old hand’ or someone new to telephony, can get on with the job of crafting an application and focus on the end result rather than issues such as SIP negotiation and RTP usage. Significantly, time to market for the development of a given solution can be considerably reduced, because applications are probably two orders of magnitude quicker to write than the traditional alternative. Vendors will typically offer their own (ideally) or a third party’s HMP software to provide the underlying telephony or media server functionality.

So, which group are you in?
Each of these five methods or approaches has its own merits, which you will recognise. One way or another, each has its price. You pay through a per channel licence fee or on a fixed fee and/or usage basis. The cost-effectiveness of what you get and the time to market result is a matter for you. Choose well, my friends!

Aculab's Prosody S with AMS Server - a more palatable sandwich for today's developer community!

Aculab is probably best known for its DSP-based hardware which has been providing the media processing power for TDM and IP-based communications since 1998. Additionally, since 2003, we have provided developers who had a preference for a software only solution to have access to the same media processing capabilities with our Prosody S host media processing (HMP) product. You could say that these products are the bread and butter of Aculab's portfolio.

As you may have seen from our recent press release, we have been working on an extension to our portfolio, the AMS Server. If Prosody is Aculab's bread and butter, then AMS Server is the jam on top! (or jelly if you prefer).

The thinking behind AMS Server

The Prosody X and Prosody S products are a solid foundation for any platform requiring voice, video and data processing, and we did not feel any need to replace them. However, a trend we saw was for the increased use of high-level scripting languages in the design of embedded software systems. The interface to Prosody X and Prosody S is a 'C' API - but we frequently hear that 'C' programmers are not as easy to find as programmers with knowledge of languages such as C# (.NET) and Python. In addition, speed of application development was another advantage cited for these scripted languages.

Another current trend is the move to a more software-centric architecture for telephony platforms. Having a software only solution allows huge flexibility when it comes to deployment, rather than tying the customer to a solution using dedicated hardware for the media processing.  This was taken into account for AMS Server - it has been designed to work alongside Aculab's Prosody S HMP software.

We are really excited by this new product - it brings the added benefits to our developer user base of faster time to market and ease of use. To find out more, visit the dedicated AMS Server page on the Aculab web site.

A crowd of daffodils and hosted clouds

You might recall the poem by William Wordsworth that begins, "I wandered lonely as a cloud." His poem may have been about 'a host of golden daffodils', but the second verse is more appropriate if we pretend that it's about the advocates of cloud computing.

"Continuous as the stars that shine and twinkle on the Milky Way,
They stretched in never-ending line along the margin of a bay:
Ten thousand saw I at a glance, tossing their heads in sprightly dance."

I'm sure there are at least ten thousand advocates of cloud computing, tossing a few heady paragraphs into their latest blog or preaching to us all from their twittering stance. "The more fool you," if you're not listening, seems to be the message.

You could say there are now two types of businesses, "Those with their heads buried in the sand and those with their heads in the clouds." That phrase would neatly sum up the present situation and, although it's not quite complimentary to the advocates, their devoutness probably means they'd miss the subtlety. Yes, indeed, the 'Cloud' is being hyped at the moment - and rightly so.

However, as with everything, there is always more than one approach. From religion, which we won't go into, to Coke or Pepsi, Google or 'Yah-who?', ..... to ..... (fill in the blanks) - those of independent mind and billions of social lemmings have all been following one trend or another since time immemorial. If open source was the right answer, Microsoft wouldn't exist. If Asterisk was the 'be all and end all', telephony equipment manufacturers would be falling by the wayside or at least ending up with double-barrelled logos (hmnn.... there's a thought). If Skype was the answer to 'life, the universe and everything', there would be more than just 560 million registered users from a global population fast approaching 7 billion.

Nevertheless, there's no denying the attractiveness of operating in the cloud. From data centres and Software-as-a-Service to communications as a service, many benefits emerge, but there is plenty of room in this universe for non-cloud operations. Where, for example, do managed VoIP services sit? They can be described as 'managed dedicated hosted' or 'private cloud' solutions. Whatever the depiction, those providers need service delivery platforms on which to host their applications and that means server-based, IP-centric, software-only enabling technology components. Ideally, those components will include a high-level API in a general purpose programming language. That leaves the application developer free to concentrate on topics such as call flow, database access and back-end processing, rather than on low-level issues involving SIP and RTP usage.

And finally, it shouldn't be forgotten that, somewhere along the silver lining of the telephony cloud, a gateway to the PSTN will always be needed. On the face of it, 'having your head in the clouds' might seem like a nice slogan for the cloud fraternity, but I'm sure they'd prefer something on the lines of 'walking on cloud nine' (or Wolke Sieben).
 
"What indeed are mere words worth?" said William.

Fax communications - the poor relation to voice and video

My previous posts in this Aculab technology blog have been mainly on the subjects of voice or video communications, which correlates well with Aculab's main customer activities where our products support services such as voice conferencing, call centre media processing, and interfacing TDM and IP communications.

An oft forgotten technology, still utilised throughout businesses, though perhaps now less prevalent, is fax. We have all been moving our business communications along with the times - investing in mobile solutions, using voice and video conferencing, getting involved in the VoIP communications space, and finding out how Unified Communications and IM might help with business communication efficiencies. Whilst many have been distracted, chasing the latest and greatest way to communicate with colleagues and customers, the humble fax machine has been there in the corner of the office, performing a key function when the newer approaches of document transfer, such as email, did not work or were not suitable.

Heading in both directions at once

Or, an alternative definition of the 'pushmi-pullyu'

I guess many of you will remember Doctor Dolittle, probably from the Rex Harrision film version, perhaps from the books of Hugh Lofting, maybe from the Eddie Murphy remake, surely not from Lotte Reiniger's silent animation. Whatever your vintage, it's the 'pushmi-pullyu' - that cross between a gazelle and a unicorn with two heads, one at each end - that challenges the imagination. A beast in eternal conflict; when it tries to move, both heads attempt to go in opposite directions. How could it make any progress?

Apply that analogy to the telecommunications market or the computer telephony market or unified communications - any label of your choice - and you might end up thinking, yes, we've got PSTN pulling one way and VoIP, let's say, pulling in the other direction. The one 'head' frantically resisting and the other, frankly irresistible.

What's really happening in the telephony market is definitely a 'pushmi-pullyu', but it's no longer a battle between opposing camps. What we see is that application developers are being asked by the market - their customers - to produce IP-centric voice and video systems. That's market 'pull'. At the same time, those very same developers are falling over themselves to offer IP-based, software-only, applications or service delivery platforms. They are 'pushing' those products onto or into the market place, because they are easier to create, sell, support and maintain. You'll note though, that they are not necessarily cheaper to buy. The end result is one party pushing with the other pulling - a 'pushmi-pullyu' where both 'heads' are going in the same direction. Magic!

Of course, vendors of enabling technology are playing their part, offering IP-based, software-only, media processing platforms with high-level APIs (C# or Python, for example). The media server or telephony engine may be drifting into the 'Cloud', but that is only one deployment option. It's a bit like saying, "premises-based CPE beats hosted delivery any day" - or vice versa. Neither statement is unconditional. Application developers who are focused on a physical, product-based model need a quicker route into the VoIP market. The greatest consumer of their time is coding and debugging so, for those guys, high-level APIs make sense, because they deliver a double bonus. Not only do they lend themselves to more rapid development, they also produce less code, which means a given 'app' is also far easier to debug.

So, who gets the last word? As Red Hot Chili Peppers sing, "Doctor Dolittle, what's your secret? Give it to me Doctor, don't keep it."

If you're looking to build telephony-enabled applications faster and more cost-effectively, give Aculab's new AMS Server a try.

There's more than one way to skin a cat

Musings on the multitude of programming language choices available to todays application developers

Yes, there's more than one way to skin a cat. You could start with the neck or the tail... meeea...oW!  Ok, Ok, I didn't mean to offend. I have, however, seen some nifty looking sporrans made out of pre-deceased, I hasten to add, wildcats from Scotland. Are programmers (application developers) a bit like cats? Cats are known for being independently minded, unlike the typically faithful, devoted, monogamous dog. In the programmer's world, perhaps that stretches to being independent in terms of the choice of their favourite programming language. How many programmers still use Erlang or Lisp, for instance?

Programmers aren't in the business of skinning cats, I trust, but they are into application development, whatever the application might be. In the world of telephony, there are many ways to write - or craft - an application, hence the analogy. So maybe Ruby Tuesday has put a spell on you or you're hooked on Groovy baby or you're a closet snake charmer (a Python in a basket case) or you spell pearl like a German or you've cast your .NET a bit wider and become a C# dresser. Whatever you choose to use, you will be making decisions along the way; from the design approach - what used to be called 'systems analysis' - to the project management approach, which might be the 'Scrum' framework, to the programming language and, ultimately, the telephony hardware.

In these days of 'software-only, IP-based systems' and 'cloud computing' it is often forgotten - or deliberately ignored - that someone, somewhere, even if it is over the rainbow, has to deal with the hardware. Software applications deployed in 'the cloud' are installed and run on hardware, but the benefits stem from someone else being responsible for those server platforms. In the world of telephony, that has lead to a fillip for hosted applications, such as those offering IP PBX or contact centre functionality, particularly when combined with SIP trunking. Of course, the problem with clouds is that they appear in lots of different forms. There are: 'Cumulus' - heaps of clouds; 'Cumulus fractus' - ragged, detached portions of clouds; and 'Accessory clouds' - clouds that develop on the body of the main cloud. The message there, I guess, is that you need to be careful with your cloud. You certainly don't want it to be a 'Nimbus' or a 'Cirrus' and it definitely needs a bit of 'Vertebratus'.

But you do want your programming language to be an 'Alto-stratus'. In terms of developing your telephony application, you should be looking at a high-level API, presented in your favourite programming language and interfacing to the telephony or media server software of your choice. In cat terms, that means you should avoid the 'shabby tabby' and settle for something more 'Alto-ordinus'. I'd recommend using a high-level programming language and API, something like C#, for example, if you're a .NET Microsoft devotee. But, as I said, there's more than one way of skinning that 'Felis'.

To find out how Aculab's latest product makes use of a high-level programming  approach using C# and Python, visit the AMS Server page here.

An IP network is what you need for your video calls

Video communications is (still) in the early adopter stage of the product lifecycle curve (PLC). As I hinted previously in my blog, it was given a big push up the ramp last week with the launch of the iPhone 4, but what it needs for mass success is ubiquity in the core network.



I believe that there are two good reasons why Apple might have chosen to provide the FaceTime video chat application over Wi-Fi only:

1.Video chat is possible over a 3G connection, but is inherently limited to a low bitrate by the nature of the 3G network

2.In contrast to 3G networks, IP networks are ubiquitous

Are there still barriers to VoIP acceptance?

Within Aculab, we're often discussing the general acceptance of VoIP and whether we're any closer to the time when traditional TDM voice will disappear. One thing that is clear is that whilst we are in the midst of a large shift towards IP voice, the general use and acceptance of VoIP is still at a slower pace than we were predicting 1, 2, 5 and certainly 10 years ago. One analogy recently drawn in our discussions was with the continental drift. Plate tectonics theory states that whilst the actual speed is very slow, somewhere between the growth of a fingernail and the growth of human hair, it is relentless and unstoppable leading to the creation of new geographic features along its path, such as mountains and volcanoes - again an analogy we quite liked. Being right on the edge of the VoIP (or plate tectonics!) shift we're all very aware of this movement but to the majority of people it remains an unseen level of detail that does not concern them.

But why the reluctance? Quality doesn't get touted as the restricting factor any more. Sure there can be issues and certainly calls across the public Internet won't reliably give the same quality as a dedicated PSTN line, but generally people are very happy with the compromise of that quality when taking into account the cost savings in the call. Availability doesn't seem the reason either, most modern voice solutions use IP at its core, of both equipment and networks.

In today's economic climate, the traditional method of moving to new technologies by 'rip and replace' seems to have outlived its day. For both financial and acceptability reasons, moving to new technology now means a slow, measured approach together with a well thought through solution to integrate existing legacy equipment - without losing any existing legacy functionality. Horror stories abound of where systems have been put in but then taken out due to, for example, the CEO losing a particular feature which he, and perhaps only he, used across their corporate PBXs. Similarly the unavailability or poor quality of a VoIP connection when calling back into the office has forced companies to rethink their telecoms strategies.

Tim Joint was recently interviewed by Erik Linask of TMC where these issues were covered in more depth and some solutions proposed to help integrate legacy PBXs into modern VoIP environments without having to lose functionality, quality or control. The term we've coined for this is 'Extensibility' - the ability to allow solutions to be upgraded or enhanced without being forced to make major changes to the existing infrastructure. Listen to the podcast here and understand more about the issues and exactly how our ApplianX IP Gateway offers extensibility by allowing the easy addition of IP solutions or networks to legacy PBX installations.

FaceTime video chat on an iPhone 4 would be great...if I knew anyone else who had one also!!

Today is the day - queues at Apple stores around the world of people waiting to get their hands on Apple's latest piece of tech. It sounds like a fantastic piece of kit, and I would love to have one (if I hadn't just splashed out on a Nikon DSLR camera then I might have been tempted). The feature I have been most interested in is the video chat application that Apple has come up with, FaceTime.

As I wrote in my previous post, this could kick start the video communications market, a feat that others have tried previously but with limited success. You may also know that one of the other topics I am following closely, and for which Aculab has a great product, is HD voice. Both technologies have much potential, but share a common problem - if you don't have the same technology at each end of the call and the ability for the call to traverse the network in the middle un-hindered, then you do not get the benefit. You will end up with 'capability islands'. Your new iPhone 4 can communicate as a phone with any other phone worldwide, but you can only video chat with another iPhone 4 owner. Similarly, if you have an HD voice enabled phone (such as those customers of Orange in the UK involved in the HD voice trials) then you can call another HD voice phone on the same network and get a high quality call.

Whilst Aculab does not itself sell phones for HD voice or video, what we can do is provide the core network technology that can join these islands so that the benefit of the improved communication technology can be spread. So perhaps whilst queuing for your iPhone 4 you should make friends with the person next to you so you have someone to video chat with.

Designing resilience into next-generation public safety communications

The team here at Aculab are gearing up for NENA 2010, which takes place in Indianapolis, USA in early June. NENA 2010 is an event run by the National Emergency Number Association (NENA) for public safety professionals, telecoms specialists and government officials, which focuses on the near and long term issues facing public safety in the USA.

NENA is calling for the migration of 911 networks to next generation E911. The idea is to move 911 systems to standards-based IP platforms and, in the process, enable citizens and those involved in emergency response to interact not only in voice, but also via text, IM and possibly even video communications.

The ultimate goal is that citizens, no matter who they are, where they are or which communications device they use, can make an emergency call and the emergency services will have the accurate location and subscriber information to find them.

With such critical communications, there is no room for error. Resiliency, reliability and interoperability are all essential, as is full integration between IP and PSTN networks. Specific recommendations for survivability and resilience (recommendations 16.10 and 16.12 respectively) have been made in the US government's national broadband plan and the FCC are already some way into making sure the new infrastructure handles these key issues.

Developers of communications solutions such as Aculab must provide the reliable and redundant connections to landline and cellular networks that carriers and emergency services providers demand. The mantra should be 'duplicate everything', so there is always a standby component when the main fails.

Protect your hardware and software elements

The media processing component of a communications server is the device (hardware or software) that handles the calls. It is clear that such a key component should be a) reliable in its own right, and b) have the ability to be duplicated in a master/slave arrangement. Extending this concept even further, it is also a good idea if the master and slave can be sited geographically remote from each other, which is not always easy if the media processing board uses an H.100 bus rather than IP for connectivity. The concept of the distributed architecture for VoIP telephony solutions is further discussed in our whitepaper.

Protect all links between the elements

Having master and slave communication servers on different sites is a great start, but what if they are linked by a single connection, and a roadworker goes through the cable with a jack hammer? What you need now is some form of link protection scheme such as a loop/ring topology. For this you need duplicated cable and duplicated ports on your media boards to support the two routes. Again, if these routes are IP-based then there are a myriad of choices for the protected connection.

Then protect anything else you missed in the first pass

How about the call control software? Whilst protection of the SS7 stack for legacy PSTN networks is commonplace, the same approach has, until now ,not been available with IP communication networks using SIP for call control. Our engineering team, with many years experience of the design of solutions for TDM and IP networks, realised this was the case and came up with a solution using duplicated SIP stacks and some clever software to control the stack mirroring. Our Dual Redundant SIP Service (DRSS) is now available as an optional feature of our field proven SIP stack, and has already confirmed itself as a hit with customers developing critical communications systems.

For someone who has been in the industry over 20 years, I sometimes feel that the transition from TDM to IP is happening so slowly that it won't be over in my lifetime! Building resilience and reliability features into IP-based systems is one way that we, in the vendor space, can speed this transition by convincing customers that the new system is going to perform better than the old one.

Achieving 'five-9s' reliability in IP-based communications networks

Is the lack of widespread support for full 'five-9's' reliability in IP-based networks  holding back the adoption of IP communications?

It is certainly something we thought might be the case, and so we set our engineers the task of providing redundancy mechanisms for IP communications , based on Aculab's SIP stack, that would enable end customers to build in the reliability they were craving.

Our goal was to enable our customers to build enterprise and service provider communications platforms that could match the reliability and resilience of a legacy TDM-based system, but also give the full unified communications experience made possible by IP.

For over 30 years, designers of TDM networks have taken every step possible to minimise network downtime in search of the mythical 99.999% availability figure (just over 5 minutes downtime per year). The basic rule has been to eliminate any single point of failure. This philosophy has extended beyond simply duplicating the network hardware - separate buildings with separate power feeds and physical connecting cables are also a key part of a resilient network design.

For the IP-core network consisting of routers that are inherently designed to utilise multiple routing paths, this is not an issue; but for hardware attached at the network edge such as media processing servers, it is not so straightforward. An IP-based media server supporting VoIP and video services and using SIP for its signalling is one such platform that sits at the edge of the service delivery network. It is relatively straightforward to duplicate the hardware parts of this server, but not so easy to duplicate the software applications running on the server.

Aculab took on the challenge and created its dual redundant SIP service feature - mirrored SIP stacks are enabled, with failover mechanisms to keep calls active on the standby when the main server fails. The use of a floating IP address with switching to handle the traffic routing to the correct active server provides the mechanism to make sure the traffic is directed to the appropriate server. 

If you would like to know more of the detail then you can access our dual redundant SIP whitepaper here.

Telecoms standards: are they slipping?

I often hear people say things like, "standards are slipping" - maybe they are talking about our politicians! But that's not where I'm going today; I just had a few random thoughts on standards, per this definition: 

• standard (n): a specification for hardware or software that is both widely used and accepted (de facto) or is sanctioned by a standards organisation (de jure)

We're all familiar with the British Standards' kite mark and the American National Standards Institute (ANSI). Internationally, there is the Internet Engineering Task Force (IETF - maybe you could quibble on that one as its RFCs are more akin to recommendations; but let's not deviate from our standard interpretation), the International Telecommunications Union (ITU-T) or the 3rd Generation Partnership Project (3GPP) or...

Never mind that the list of standards bodies goes on and on, my first thought was, "Isn't it maddening that their collected output is seemingly endless?" The standard response is "yes", by the way.

Don't get me wrong, it's certainly a good idea that the graphics card you buy to upgrade your computer is built to the PCI electro-mechanical standard. You want it to slot in snugly, regardless of whether you bought it on eBay or from your local RadioShack. There might be a bewildering array of options for full-length, half-size, half-height, low-profile, etc. but the point is, it fits, because it's been standardised, which is good.

So much for hardware; then there was software.

The need for a standard specification is suggested by recalling the not too distant past, when everyone queued up to criticise Cisco for its so called 'Skinny' interpretation of SIP. Standards are good; right.

VoiceXML (VXML) is a standard that gets a mixed reception, depending to whom you're talking. Some engineers say things like, "It's not that easy or intuitive for a novice to grasp. It'd be just as quick to use a general purpose, high-level language."

Advocates of VXML as a standard for specifying interactive voice dialogues between (wo)man and interactive voice response (IVR) machines would surely take a different view. And, to be provocative, I suggest that Call Control eXtensible Markup Language (CCXML) was an afterthought - or as Homer said, "Oh, so they have Internet on computers now!"

The problem with such standards is that they are so niche. Nobody writes a business application entirely in VXML (or indeed, in MSML, MSCML, MGCP, MEGACO, ...). Quite likely, such applications are written in a general purpose, high-level language. These are de facto standards, such as Python, Ruby or C#.

That brings me to media servers and the argument for using niche standards to control them. I suggest application portability is a myth. A well structured, high-level API for voice (and video) may be proprietary, however, it is an arguably better option than using a niche standard, particularly if the API library uses the same language in which you write your business application.

Incidentally, the Battle of the Standard was fought on Cowton Moor, near Northallerton, on the 22nd of August, 1138. Historians on either side have since claimed at least a moral victory for their sponsors. So, it seems that standards never change.

Interacting with the electorate using technology

It may have escaped your notice, but the 51st state of the Union, that's Britain (or England as most Americans like to call it) by the way, is holding its elections six months ahead of the usual mid-term elections. Like the other distant states, Alaska and Hawaii, Britain maintains the habit of 'doing its own thing'. There are regional governments here too, however, the upcoming elections are neither for the Welsh Assembly nor the Scottish Parliament; they are purely for the Westminster Parliament.

One thing that's created a stir over here, this time around, is the presidential style television debates between the party leaders. These have been entertaining or boring, depending on to whom you talk. I think, though, that the organisers have missed a trick. Or, they've not had the courage of their convictions - or the party leaders have 'chickened out'. I mean, come on, they could surely have gone for a bit more audience participation. How much of a risk would that really have been?

Some or other enterprising customer from Aculab's developer community would willingly provide state-of-the-art call centre technology in order to liven up the debates.

The kinds of technology I mean are things such as:

• Outbound call centre dialling to canvas voters 
• Inbound mass calling platform to register voters' opinion of the participants immediately post debate, such as the poll conducted by SKY News after the debate it hosted
• Conferencing platforms to enable voters to participate directly in the live TV event, posing questions to the leaders in real time

For Aculab, these platforms use media resources that can be considered our core competence, such as active speaker detection, support for multiple voice codec types (fixed, mobile, narrowband, wideband), TDM and IP connectivity, highly effective call progress analysis (CPA) and automatic call distribution (ACD).
These technologies have been used numerous times to build systems by our developer partners such as Dolphin Systems, Future Technologies and Noble Systems.

Perhaps the use of some of these technologies might be a turn off for the typically reserved British nation, or perhaps it was thought that just having the three main contenders on screen for 90 minutes would be enticing enough in its own right - but I for one did not persevere to the end, and went channel hopping in search of the World Championship snooker instead!

Serving the needs of critical communications systems

Recent emergency situations, such as the earthquakes in Haiti and this week in China bring it home to us that when disasters like these occur, the emergency services and the general public who are directly affected rely heavily upon communication systems to co-ordinate rescue efforts and receive the most up-to-date information.

As a supplier of enabling technology that often gets installed into the communication systems used by emergency services, Aculab has a duty to enable such systems to operate flawlessly, to provide communications clarity and to offer utmost reliability.

Several recent technological advances are playing their part in providing world-class Integrated Command and Control Systems (ICCS):

The first example is a technique we have developed to enable the concept of equipment duplication used in TDM communications systems to give 'five 9s' reliability in an IP-based communication system. The Dual Redundant SIP Service (DRSS) enables the SIP stack used for the call control to be duplicated over separate hardware platforms to give much improved fault tolerance capabilities. By keeping the two SIP stacks synchronised, a call being set up or in progress will not  be dropped even if the main server fails mid-call or during call set-up.

Another example where new technology will give advantages to emergency communications system developers is in the adoption of video codecs and wideband audio (HD voice) codecs on communication platforms. In a critical communication scenario such as a 999/911/112 call, to be able to have the best call clarity is obviously an advantage. In the UK, a system called Silent Solutions is used to deal with silent calls made to the emergency services. Accidental 999 calls happen all the time, but how do operators know when a silent call can actually be a real call for help? In a recent murder case, a teenager was abducted but managed to make a 999 call on her mobile, however, she was unable to speak and the call was disconnected moments later. Had this call been a wideband call, then the operator might have been able to make out more of the low level background conversation and determine that this girl was in danger.

Video communication capability can also offer extended benefits to emergency communication systems - sometimes providing a visual link can portray a situation in greater clarity and with greater speed than an audio conversation alone. For emergency calls to/from people with disabilities such as deafness, the ability to convey a message visually can be vital.

To find out more, the emergency services page on the Aculab website is a good starting point; or if you are planning to be in London next week at the BAPCO exhibition, then drop by our booth (452).

Extending Innovation: Aculab's Prosody X powers Comsys' new 'MVNO-in-a-Box' solution

I am always pleased to share information about how Aculab's customers are using our enabling technology products for their end users. Comsys, a long standing Aculab customer, has launched its 'MVNO-in-a-Box' solution, which provides all the tools necessary to start an MVNO within a short timeframe.
An MVNO (Mobile Virtual Network Operator) is a company that provides mobile phone service without having its own licensed frequency allocation of radio spectrum and, in some instances, it will not have all of the infrastructure required to provide mobile telephone service.

Virgin Mobile successfully launched its mobile virtual network in the UK in 1999, reselling capacity from T-Mobile. It now has over 4 million customers. The US has also seen MVNO success from multiple MVNOs. Denmark-based company, Tele2, who uses some of Comsys' products and services for its solutions, has successfully implemented and rolled out its MVNO services in Demark and other European countries.

Today, many mobile providers are focusing on niche markets with fewer subscribers, meaning that they need to ensure a high degree of flexibility whilst retaining a low initial investment. As a result, Comsys has developed the 'MVNO-in-a-Box' product, which contains everything that a company needs to start its own MVNO or MVNE (Mobile Virtual Network Enabler). The 'MVNO-in-a-Box' solution offers flexibility, scalability and minimal initial investment. It includes a number of communications services, such as pre-paid and post-paid voice services, data communications, video, provisioning, messaging, voicemail, HLR, CRM tools, and data warehousing.

You can learn more about the Comsys 'MVNO-in-a-Box' solution by visiting www.comsys.net and don't forget to visit Aculab's website to find out about the products used in the solution.

Which wideband codec to choose?

 In the second part in my series of articles on HD Voice, I discuss the wideband codecs currently available and deployed, and suggest which might be the best choices for a wideband voice platform. Part 1 in this series discussed the question of how much bandwidth do you need for voice solutions.

Wideband (up to 8kHz audio bandwidth) codecs currently available and deployed include:

HD Voice - how much bandwidth do you need?

In this article, the first of a series covering HD Voice, we discuss the issue of audio bandwidth for VoIP systems, and in particular, how much audio bandwidth do you actually need for voice?

Voice communications systems in use today are based on traditional telephony standards that haven't changed much since the 1950s. These standards were set at that time and limit the information bandwidth for voice communications to 300-3400Hz (200-3200Hz in the US and Japan). However, if one analyses normal conversational speech, it typically covers the frequency range 0-8000Hz. In fact, only 20 percent of the frequencies utilized by the human voice are transmitted in the 300Hz to 3.4kHz range. Furthermore, the human ear is capable of hearing frequencies up to 18 or 20kHz. Back when these standards were set, it was felt that a voice channel limited to 3.4kHz would be good enough and ever since that time we have all accepted that telephone conversations would have a slightly muffled tone.