Posts

VoIP applications need dynamic routing decisions

If it’s Friday, I’ll Take the Scenic Route Home

VoIP applications need dynamic routing decisions

VoIP applications need dynamic routing decisions

In my opinion, Waze is the best navigation application in the market today. Actually, Waze is much more than just a navigation app: it’s a community of travelers and commuters who are constantly contributing to form one of the earliest and largest crowd-sourcing platforms. By using on-line navigation data and user notifications, Waze maps traffic jams and sends drivers a variety of notifications including hazardous situations on the road, police presence, and speed cameras.

When it comes to navigation setup, Waze is very much like other navigation applications; the navigation setup is static. The main setup decision related to routing that the user is required to do is choosing between the route with the shortest distance or the one with the fastest time.  In addition, the Waze user can decide to avoid toll roads, highways, ferries, complex turns and dirt roads.

The fact that the setup is static is a real shortcoming, since routing preferences may change during the course of a single day. For instance, in the morning when you’re in a hurry to get to work you might not mind using toll roads. But on your way back home, you might be quite happy to take it easy and go via the scenic route, enjoying the springtime aroma of orange blossom along the way. To achieve this with Waze or any other navigation application, you would need to modify your routing preferences twice a day.

VoIP routing applications suffer from the same issue: how to make decisions based on a variety of criteria. In an ideal scenario where the network is free of any impairments, the main VoIP routing criteria would simply be the cost to the desired destination (i.e. least cost routing). However, in real life, there are so many other competing criteria which need to be taken into consideration, e.g. VoIP delay, VoIP quality, bandwidth, connection health, the time of day, user policy, security, load balancing and call admission control.

Unlike a navigation application, in a VoIP routing application, most of these additional criteria can’t be configured with a simple binary yes or no. For instance, in the case of voice quality, the user would prefer the call to be transported via the route with the best quality while, at the same time, ensuring that the cost is as low as possible.  The same goes for voice delay, signalling impartments, etc. The network administrator would like his calls to take the optimal route, but how can he configure the priorities and weights for these competing criteria?  A tricky problem.

Currently, most VoIP routing applications handle this issue by associating weights to the main routing criteria. This means that the user associates a weight to each criteria giving each criteria a priority.  The routing algorithm takes into consideration the criteria based on their associated weights and calculates the routes accordingly.

An alternative scheme is basing the entire routing calculation on one criterion (usually cost). Any additional routing considerations are applied to the main rule as relevant on a call by call basis.

For instance, all routing rules can disregard VoIP quality in general, but a VoIP quality condition will be applied ONLY when it is relevant, e.g. any calls made specifically to New York must be routed via a high quality connection disregarding the cost.

With this per route association approach, routing rules can get quite complex but since the additional conditions are applied on a route by route basis they are still easy to configure and easy to maintain. Imagine how convenient it would be to be able to configure a routing rule which, for example, determines that calls from the CEO to the New York sales manager on Mondays between 8:00am and 10:00 am must be routed via best quality route. Now try to figure out how to configure the same routing rule using a Waze-like static routing configuration.

I wish that Waze had route options like playlists, aligned with users’ personal moods: happy routes, contemplative routes, romantic routes, routes for birthdays etc., maybe even combined with recommended music per route. In today’s dynamic lifestyle, we can’t rely on a static, generic setup.  We need tools that let us customise our needs as simply as possible, since routing is everything.

 

To find out more about how AudioCodes helps simplify call routing in complex enterprise and service provider VoIP networks, download our white paper today.

The path to replacing MPLS with broadband

Sustaining High Voice Quality Over Broadband

The path to replacing MPLS with broadband

 

The path to replacing MPLS with broadband

Hosted enterprise communication offers a good solution for enterprises looking to move their communication to the cloud and by doing so, reduce their CAPEX investment as well as benefit from a cloud managed solution that is regularly updated for supporting new technologies and features.

These benefits typically come with a caveat, however, a requirement to connect through MPLS to the communications service provider in order to reduce network impairments issues that impact voice quality.

MPLS cost TeleGeography

Source: TeleGeography

 

MPLS comes with a high price tag. The chart above shows typical costs of MPLS in key countries in comparison to broadband. For example, in the US, monthly costs for 10 Mbps of MPLA would be approximately $1,250 while broadband would be slightly over $100.

This represents a significant difference that calls for realizing the cost reduction opportunity. However, the risk of not being able to ensure high voice quality keeps many communications service providers away from recommending this option to their enterprise customers.

Voice QoS is a combination of codecs and other algorithms

Voice quality is determined by network characteristics such as delay, packet loss and jitter combined with the tools used to mitigate network impairments once they happen.

Many of the communications services are using technologies (phones and network servers) that are built for LAN environments or dedicated networks, are not built for the open Internet.

IP-Phones and applications are using codecs such as G.711 or G.729. These codecs are not built for the open Internet both from the resilience and voice quality perspectives.

Voice algorithms such as Jitter buffer need to be tuned for the network and additional algorithms such as Forward Error Correction (FEQ) and packet loss concealment should be implemented.

The end result is that many deployments today are not built for working over broadband and therefore the common practice is to default to MPLS, thus increasing OPEX and delaying customer acquisition (as setting up MPLS may take a few months).

Perfecting voice over unmanaged networks

Yet communications service providers can allow their enterprise customers to benefit from lower cost broadband without replacing their network elements or customer’s phones.

To realize this, however, a few things are required:

  • Real-time monitoring of the voice running over the network
  • Transcoding to codecs built for unmanaged networks such as OPUS. OPUS has resiliency built into it by design and supports a wide bitrate range going up to ultra-wideband.
  • Implementation and tuning of algorithms such as adaptive jitter buffer, FEC and packet loss concealment
  • Smart routing and balancing of traffic between several broadband links if more than one link is available

AudioCodes’ VoIPerfect offers all these capabilities and allows communications service providers a route for easy adoption of this technology by deploying SW or HW elements at their access and customer premises while not replacing the existing deployed elements.

To learn more about the VoIPerfect and experience a real demo click here (http://online.audiocodes.com/voiperfect-for-ucaas-providers).

VoIP Quality Jitter Delay and Packet Loss

Is VoIP Jitter, Delay and Packet Loss the Best Measure of Voice Quality?

VoIP Quality Jitter Delay and Packet Loss

“One of the values that I think men in particular have to pass on is the value of empathy. Not sympathy, empathy. And what that means is standing in somebody else’s shoes, being able to look through their eyes.” Barack Obama

Empathy – being able to feel sorry for someone else’s troubles – is a basic ingredient for good mental health. However, sometimes, when irony is involved, empathy might turn to ambivalence.  For example, you will naturally feel empathy when you see or hear about a house going up in flames, but you might even crack a smile if the house in question is the fire department. (Of course that would happen only if no one was injured, right?)

We recently had voice quality issues in our corporate telephony system. Now that might happen in any organization, but when it happens in AudioCodes, the company which has become the hallmark of HD VoIP, that’s ironic.

Our IT guys brought their usual armour to battle and started taking on the packet loss with Wireshark (network protocol analyser), upgrading this and downgrading that.  Then they started looking at the AudioCodes products on the VoIP network; scrutinizing the latest IP phone firmware, restarting the SBCs, disconnecting the MGW.  And still, they couldn’t find anything to help pinpoint the problem.

After a week or so, one of my colleagues placed a call and couldn’t stand the noise on the line.  Naturally, he cut short the call as cellular SP has “trained” us to do over the past two decades. And since he is the Product Manager for AudioCodes Management Solutions, he decided to try troubleshooting the problem on his own (15 years in R&D can come handy sometimes), using the AudioCodes Session Experience Manager.

Now I have to apologize up front since at this stage the story gets a little corny.  He found that a substantial amount of the off-net calls originated by the UC system were faulty with a poor quality score.  After conducting a short analysis with our IT department, he found a misconfiguration of the VMware machine running one of the IPPBX servers.  He wondered why our own IT guys weren’t using the AudioCodes Session Experience Manager. Could it be as a famous man once said, “familiarity breeds contempt”?

I am not relating this story to point shortcomings on the part of our IT department (God forbid!) or alternatively to glorify an AudioCodes product.  A vendor who speaks about his own products is almost as bad as a mother who talks about her own children.  My point, rather, is to elaborate on the concept of VoIP quality monitoring.

It is human nature to reach a conclusion by reviewing the consequences of actions. The human brain is constantly on an endless quest to solve riddles and reach conclusions (Gestalt psychology or Gestaltism).  Therefore, it’s perfectly normal for an IT engineer to analyse the VoIP network, search for the causes of poor quality such as packet loss, jitter and delay and based on the analysis, evaluate the call quality.

From my perspective, this analysis method is problematic.  It’s like commenting on the taste of a casserole by evaluating its ingredients – before even cooking the dish. Voice quality can’t be accurately evaluated by reviewing only the relevant network impairments (jitter, delay and packet loss). An accurate measure of voice quality needs to be taken at the VoIP edges (MGWs, SBCs, IP phones, soft clients) while taking into account the vocoder, jitter buffer type and depth (static, adaptive), packet loss metric (Network Packet Loss Rate, Jitter Buffer Discard Rate) and more. This information can’t be obtained by only analysing the traffic.

Epilogue

There is a mistaken belief in the industry that VoIP Quality Monitoring applications are like insurance policies -you buy them hoping not to use them. This belief is due to decades of trusted legacy telephony and basic trust in the organizational network, devices and solutions. In Reality, VoIP Quality Monitoring should be considered for ongoing use for the following:

  • Day-to-day, end-to-end quality monitoring and assurance operations with the ability to perform proactive actions to prevent quality issues
  • Root cause analysis for diagnostics when VQ issues arise

So if you are having VoIP quality issues, I empathize, even though after reading this, you might smile at the irony.

Routing

Super Creativity in Routing Diversity

Routing

“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things”- Steve Jobs.

Recent researches show that “super creativity” is the way the brain makes the connection between different segments of the brain. Furthermore, it’s all about amount and diversity of connectivity. What’s connectivity? Brain anatomy (circuitry) or routing?

Perhaps both?

Karl H. Pfenniger (origins of creativity; Oxford 2001) claims that creativity involves the association of diverse and apparently unrelated entities and that the brain’s plasticity allows for neurons to adapt their connectivity to function. In other words, new semantic connections will not only be associated or correlated but over time will become hard-wired in the network of associations. So creativity is related to routing diversity.

Routing in the network layer

Data routing’s main pride over the last two decades is the distributed routing architecture. Using various routing protocols (RIP, OSPF, EGRP, BGP, etc.), networks are created and shattered dynamically and automatically. Routers are totally independent and are allegedly the ultimate “plug and play” products. Hmmm…. that’s almost true. For every product there are usually two parties – the vendor and the user. Routers are the first products which users can’t use without the assistance of a mediator – “network engineers”. That’s because while a single router configuration may be simple, designing an architecture of a complete network of distributed routers is very complex.  Over the years there have been several failed initiatives (e.g. FORCES RFC, AT&T RCP) to standardize centralized routing architectures. The emergence of Software-Defined Networking (SDN) reshuffles the cards. SDN architecture is dynamic, manageable and mainly cost-effective. SDN decouples the network control and forwarding functions, enabling the network control to be centralized.  The underlying infrastructure is abstracted and used by applications and network services.

VoIP level routing

Routing in VoIP architecture lags considerably behind data routing. VoIP routing is much more complicated than data routing. Data routing is based on layers 2-4, while VoIP routing rules includes parameters from layers 2-7.  Since the initial design of the enterprise VoIP network gave control to the Soft-Switch or IP PBX, routing was typically based on static routing tables. The situation becomes complicated for off-net calls. IP-PBX/Soft Switches “get rid” of such calls by directing them to the nearest GW or SBC.

In the case of multi-branch organizations, a single VoIP network may have several IP PBXs from different vendors, as well as MGWs and SBCs. The complexity of such heterogeneous VoIP networks is rising all the time. Each IP-PBX, SBC and MGW in the network has its own static routing table; a distributed system in which the included elements don’t communicate with each other.

SBC vendors have tried to solve this complicated situation in two ways:

  • Routing Manager – a static application which helps to construct huge dialing plans and routing tables and then download them to the SBCs in the network as static tables. These files are large and complicated, allowing vendors to charge a high price for the professional services that build them.
  • Session Router -a “primitive” SIP proxy located in the center of a star formation network that performs hop-to-hop routing of the call signaling. The Session Router doesn’t solve the problem as it dictates that all the VoIP signaling will be directed via one route and leaves the routing to the VoIP peers to the SBCs and MGWs.

“Shoot for the moon. Even if you miss, you’ll land among the stars” – Norman Vincent Peale.

The scalable & manageable VoIP routing solution

VoIP Routing Controller (VRC) is a holistic, dynamic routing manager based on Software-defined Networking principles. The VoIP routing controller decuples the device layer from the network routing and policy layer, automatically creates complex VoIP networks, and simplifies routing rules, monitoring and management configuration.

Organizations’ VoIP networks are constantly evolving due to a variety of factors; mergers & acquisitions, new locations, integration of new & old IP-PBX (or even PBX) and integration of SBCs and GWs. In addition, there is organic growth of an organization and accompanying technology evolution such as introducing UC to the network and consolidating IP-PBX. All of this makes managing the organization’s VoIP network a nightmare.

Unlike the routing manager and the session router mentioned above, the VoIP routing controller is neither a configuration element nor a SIP proxy (or any other SIP element for that matter). The VRC is a dynamic routing controller which calculates end-to-end routes.

All SIP network elements (i.e. SBCs, GWS) register to the VoIP Routing Controller automatically as they boot-up. The SBC and MGWs update the VRC with all the peer connections, (the SBC / MGW connections to IP-PBX, PSTN, SIP trunk, user interfaces, etc.) The VRC learns about the SBC and MGW automatically, and it’s done dynamically. Every change in connectivity and configuration is reported to the VRC.  Eventually, the VRC has the complete network topology connectivity and health picture.

The VRC also assists with the VoIP network design and creation. With the VRC, a network can be formed in one-click. The administrator can choose between mesh, star or dual star formations and all the connections are automatically configured in the SBCs and MGWs.. This literally saves days of professional services as there is no need to configure hundreds of classification rules, trunk groups, profiles and routing rules. Everything is done automatically by VRC. For customized network connections, the administrator just draws a line and the connection is configured automatically in the SBC or MGW. The same is true regarding erasing and modifying connections. Configuring connections between SIP elements is as simple as drawing a line. And all of this is provided through an intuitive graphical and simple user interface.

The VoIP Routing Controller deals with users’ attributes to optimize routing calculations. It imports and aggregates users’ information and huge dialing plans from different sources (i.e. LDAP server and csv files) and groups user and dial-groups for routing calculation and implementation of number portability.

How does this work? When an SBC or MGW receives a call, it sends a query to the VoIP Routing Controller by REST API. The query includes the entire set of call information (i.e. sip:invite) The VRC calculates the entire route end-to-end and sends the entire route back by REST API. From there, SBCs and MGWs perform the call and when the call terminates, the last node in the route sends a notification to the VRC. The routing calculation may be done using a variety of decision criteria, including: priority, time based, least cost, quality, connectivity, user and dial group..

Testing Creativity

Close your eyes and imagine ten or more different animals. OK, now open your eyes and write down the imaginary list.. This simple test can differentiate between Walt Disney and Steve Jobs and the rest of us mere mortals. Where most of us will imagine cows, donkeys, sheep and maybe a lion, in the “Super Creative” list you will find anything but “regular” animals, instead you will find the likes of Capybaras, Fennec Foxes, Kinkajous, and Servals.

Routing rules and manipulations are complex and can’t be implemented on-line. Therefore, one of the VRC’s important features is the “test route” and “test manipulation” which allows for testing any rule and policy that was created in the VRC and immediately seeing the impact on the routing and policy.

Conclusion

The VoIP Routing Controller is a very much needed solution.  It reduces the operational time spent on designing and provisioning the network topology; it dramatically reduces OPEX by avoiding routing configurations of many VoIP network elements; it lowers the need to rely on telephony experts; and it reduces the time spent on adopting evolutions in the network.

Privacy Security

What Do You Know about OTT Voice Usage in Your Enterprise?

Encryption doesn’t always equal privacy

IT departments have all the means necessary to manage voice communication over the enterprise network and know the ins and outs of those communications. Some enterprises have compliance requirements to which they must adhere, some have security considerations and others have reasons to “know what’s happening in their network”.

With traditional VoIP systems, achieving the above is relatively a simple task.

However, OTT VoIP traffic is a different story. And in the case of OTT, most enterprises settle with one of the following options:

  • Block it
  • Live with the reality

The question is, are these the only two options available and what do enterprises really want to do about OTT VoIP?

Border TURN server

Some enterprises are adding a new entity to the border of their network, a border TURN server that forces all VoIP media traffic to go through it. This includes enterprise managed VoIP as well as OTT. VoIP media that doesn’t go through the border TURN server is blocked.

Adding this entity and blocking all VoIP media that doesn’t go through the border TURN server creates a problem for WebRTC communication because only one TURN server address can be provided for the peer connection establishment procedure. Since many services require media to go through an application TURN server, the border TURN server is left out of the flow and media that doesn’t go through, is blocked.

In a post I published last week together with Dan Burnett (co-editor of WebRTC standards) on WebRTCStandards.info (where we publish updates about what takes place at IETF and W3C with regards to WebRTC), we talked about RETURN. In a nutshell, RETURN encapsulates two TURN servers into one by adding the border TURN server as a configuration option to browsers. Details and illustrations can be found in the original post.

Since WebRTC media is always encrypted, what is the point in requiring it to pass through the border TURN server?

What can be extracted from encrypted communication?

Privacy SecuritySince all media flows through the border TURN server, there are some basic things it can “know” – such as the source, destination and length of a call.

With this knowledge, the server can block calls from black listed addresses, limit/monitor call duration and collect this information.

These capabilities are pretty basic and I wanted to know if there was more a border TURN server can detect in an encrypted media stream. To better understand, I turned to Yossi Zadah (who is already well known on this blog) and to Ilan Shallom. Ilan is a Professor at Ben-Gurion University and founder of a speech recognition company that today is part of AudioCodes. His technology is the brain behind our VocaNOM solution.

Some might be surprised to learn that there is a significant amount of information that can be extracted from an encrypted media stream. There are studies that show it is possible to identify the language of the conversation. Other studies show it is possible to unveil the identity of the speakers on such a call and even create approximate transcripts of encrypted VoIP calls by identifying words in the stream.

There is also a thesis specifically relating to Skype using Silk (from back in 2011) that details information that can be learned from such conversations.

Key Takeaways

  • Border TURN servers are being deployed at enterprises. Though they impose problems on WebRTC communication, RETURN is planned by the IETF as a solution.
  • Given the limitations border TURN servers impose on OTT traffic, my personal view is that they would be counterproductive in most cases as they limit Bring Your Own OTT (BYOO) in the enterprise
  • If you thought that your WebRTC call is private…think again.
VocaNOM in Amazon AWS Cloud

How Amazon AWS Scaled Up Our Business

For several years we have been in the process of enhancing our products to allow them to live in the cloud, a good example of this is the virtual SBC. In this context we have taken VocaNOM one step further and changed it from being a product to a cloud service running on Amazon AWS.

The Amazon team was pretty excited about this and conducted an interview with our VocaNOM Product Manager Yacov Tzadikov. More about the magic of VocaNOM below the clip.

VocaNOM in a nutshell

We all know what personal assistants are, Siri being one good example. Less common are personal assistants at the enterprise level. As an employee in an enterprise, not all of the enterprise information is stored on your mobile device and synced.

VocaNOM comes to solve a few fundamental issues:

  • How do I find contact details of a colleague who is not in my contacts?
  • How do I call this contact easily without starting to search my contacts when not really free to do so? (e.g. while driving)
  • How do I make sure my enterprise contacts are always in sync?

The scenario using VocaNOM is as follows:

  • You press a quick dial on your mobile or desk phone
  • You state the name of the person you are looking for and on which device to call him/her
  • The call is connected

This is as close to hands free/hassle free as it can get (that is until we have brain-controlled systems where you only need to think about the person you want to call).

No long search in the corporate directory or phone contact list and no driving while typing the name of a person (which is dangerous and rightfully illegal in many countries).

The idea behind VocaNOM is simple but can be realized only when you have a technological and product heritage as available at AudioCodes. The ingredients required to achieve this included:

  • Great and accurate speech recognition technology fully controlled by the company so we can modify and adapt the technology to run in any environment
  • An SBC that connects to any existing PBX and UC environment

All this was combined into a product that was installed on premise at enterprises. But we wanted more… We wanted to make the on-boarding of new customers as simple as possible. We wanted to make their buying decision risk free. We wanted to let people try it out instantly. The answer to this was to move VocaNOM to the cloud and offer it as a service.

Moving to Amazon AWS

The new architecture of VocaNOM as a service in the cloud can be viewed in the diagram below.

VocaNOM in Amazon AWS Cloud

In the Amazon cloud we have all the components required to run the VocaNOM service. These include the IVR and the Automatic Speech Recognition (ASR) SW as well as the web management interface. The VocaNOM system synchronizes with the company directory and stores contact information on Amazon RDS (data base).

Additionally, the AudioCodes cloud SBC takes care of passing the speech from the user to the ASR system for recognition and later to send the SIP instruction for connecting the call between the two users.

Since enterprise PBX environments vary including VoIP and TDM systems and since there is a need for a secured communication between the enterprise and the cloud in order to avoid fraud, there is a small enterprise SBC that the enterprise’s IT installs within minutes in order to make this VocaNOM magic work securely and in any environment.

Since this service is sold today both directly to enterprises and through service providers to their business customers, VocaNOM comes with a 3 level multi-tenancy management system to allow service providers to easily manage their customers.

By making VocaNOM a service in the cloud, we managed to significantly shorten the on-boarding process, making it a simple, risk free IT decision to try out the product. Since VocaNOM is addictive, making this service easily accessible created great momentum in the growth of this business and the number of customers using the product.

Although VocaNOM is great to use as it is today, the development team has a few cool rabbits in their hat soon to be pulled out, which will add more fun features to the service.

All this probably sounds great but you don’t need to believe me, try VocaNOM for free today and experience it yourself.

Multi-Tenant-SBC-Use-Cases

Angelina and The Multi-Tenants

When Angelina Jolie plays in a feature, it’s reasonable to assume that she would be playing a close role to the meaningful relationship in the movie. In “Gone in Sixty Seconds”, Sara (Angelina Jolie) is the main star’s (“Memphis” Raines played by Nicolas Cage) girlfriend, however, Memphis’ closest relationship and most meaningful dialogs are not with Sara, but rather with Eleanor,  a customized 1971 Ford Mustang Sportsroof. In the dramatic reunion between “Memphis” and “Eleanor”, he speaks to the car and touches it tenderly in the most romantic of moments.

Multi-tenancy is all about relationships, or more precisely, the lack of relationships between tenants. Multi-tenancy refers to an architecture where an application running on a server or designated hardware, serves multiple clients (tenants). Multi-tenant systems emerged hand-in-hand with the cloud rush. As more services move to the cloud and are offered as a hosted SaaS, multi-tenancy becomes more and more relevant.

Users are wary of a multi-tenant architecture due to one main reason – the fear that a single system serving a large number of organizations may present a viable security breach. That’s why multi-tenant applications are described by marketers with the following adverbs; separated, partitioned, segregated, non-bleeding, etc., implying that a user from one tenant can’t penetrate another tenant’s space served by the same application.

As the visualization trend grows, multi-instance architecture is being suggested as the ultimate remedy to the all multi-tenant architecture weaknesses. Multi-instance architecture is simple, adding a new instance of the application for each tenant/customer, eliminating the potential for any security breach. However, in life there are no free lunches and multi- instance modularity and elasticity come with a cost, some aspects of which can be listed here:

  • Waste of  Compute & Storage
  • Multiple applications to manage
  • High availability complexity
  • Upgrades “One by One” instead of “One and Done”
  • And more…

Tenant size in a multi-tenant architecture can vary and therefore the instance CPU, memory and interface allocations, should be optimized so as to not waste resources for small-sized tenants on the one hand and not to allocate too many instances for a single tenant/customer on the other. Multi-instance is like shopping in a mall with a bunch of $100 bills with no option to get back change. So when you buy a soda, you may lose $98. Similarly, it would be a great waste to allocate an instance with a capacity of 1,000 concurrent sessions to a small tenant for which 10 concurrent sessions are more than enough.

So how complicated is it to convert a single tenant system to a multi-tenant system? The “screwdriver fixer SW architect” intuitive reaction will be “piece of cake”. Let’s associate a “tenant ID” to all our internal and external tables and, hocus pocus, we have a multi-tenant system. This might work for some tenants who are not totally vertically separated. Tenants may have shared interfaces, for example, a multi-tenant SBC may have a number of tenants sharing a single interface or several interfaces of a SIP Trunk. The figure below shows a few of the possible use cases relevant for an SBC.

Multi-Tenant-SBC-Use-Cases

A multi-tenant system should be a fully scalable, “non-bleeding” partition per tenant running on a single shared physical entity. In should support per tenant configuration, monitoring, reporting, analytics, alarms and interfacing.

A real time system (e.g. SBC) should provide each tenant with optimal real time performance, as each session received by the system is classified and processed only through the tenant’s “orbit”.

Full flexibility should exist to move a tenant with its entire configuration between physical servers and physical locations, assuming extra server capacity is available on the site.

Summary

Multi-tenant options are many and should be chosen following a prudent analysis, otherwise, you may choose the most beautiful single instance and end up with bunch of tenants to foster.

Survey Results - Top VoIP Features

Survey Review: What VoIP Buyers are Looking For

Back in March, I wrote about enterprises moving their VoIP communication systems to the cloud and why it is more complex than simply putting a credit card number on a website. In that post, I referred to what Don Sadler from Software Advice wrote about 3 Ways to Keep Your VoIP Service From Going Down With the Internet.

The guys from Software Advice were kind enough to send me the results of their latest survey – Small Business Buyer View 2014 and I thought it would be worthwhile sharing the results with our readers.

Survey Key Takeaways

There are several findings in the survey I find interesting. Let’s go over them one by one.

More than half of prospective buyers were investing in business VoIP service for the first time.

Most of us, techy, VoIP savvy people, tend to believe VoIP is common in most businesses. I mean technology is around for over a decade now. How much time do those SMBs need to get going? For many of us, VoIP as we know it is old school; we are looking today at more advanced variations of VoIP like WebRTC that bring VoIP to the browser.

The reality is that most SMBs are not connected to VoIP services. Itzik Feiglevitch from AudioCodes presents more information about this in a diagram based on an analysis he has done.

Worldwide-SMBs-connected-to-VoIP-Services

The answers received in the survey fall nicely within the general point of this diagram – there is still a large market of SMBs out there that haven’t yet made the shift to VoIP.

Buyers were primarily concerned with reliability and scalability when evaluating new phone systems

Scalability is one of the advantages of going cloud but moving VoIP communication to the cloud doesn’t really increase reliability. There is the reliability of the servers themselves that typically improves because a VoIP communications cloud provider would normally have a stronger team of IT expertise that make sure the service is always on. However, having all the traffic go up to the cloud and back and the dependency on the link to be always on remains a challenge.

As explained before in my post All You Need is Cloud, the on-premise SBC would help mitigating this challenge by providing resiliency, optimized call routing, call cost optimization and QoE.

No buyers were interested in an on-premise IP-PBX, while a vast majority wanted a hosted solution

This is a clear trend we see across all businesses of different sizes and for different services – shift to SW solutions and cloud services. Having said that, concerns raised in the previous point must be addressed.

77% of SMBs are looking for services in the browser

Another interesting point that was not part of the “key Findings” presented at the top of the survey but did draw my attention, is the requirement for Web based solutions.

Many SMBs are probably not even aware yet of WebRTC but they are experiencing more and more services that are provided in their browser. Seeing that 77% actually preferred VoIP in their browser is an interesting indication for the potential of WebRTC in the UC for SMB space.

Survey Results - VoIP Deployment Preferences

Auto Attendant Tops the List of Desired Applications

The survey was seeking to learn the most important features buyers have on their decision checklist. The diagram below shows that Auto Attendant is well positioned on this list.

Survey Results - Top VoIP Features

Auto attendant is the way to navigate through a company’s directory instead of speaking with a real person who would transfer the call.

What if you could just say the name of that person, or what if employees could dial to anyone on their contact list, company list of suppliers and customers by just saying their name?

Based on AudioCodes advanced voice recognition technology, we provide this service today in the cloud, connecting to any PBX or hosted VoIP system.

Why is this survey important?

Understanding the criteria based on which SMBs make their buying choices is important. It reassures us about the “move to the cloud” trend but also clarifies the need to continue and provide reliability in the process.

One-Fish-Two-Fish-Red-Fish-Blue-Fish-by-Dr-Seuss

A Mouse has cut the Wire: I can’t hear you…..

 [Post is better viewed on the blog Website]

 

When I was a kid, I loved reading the Dr. Seuss books with the fun and educational rhymes. As an adult, I loved reading them to my own children when they were young. Some things never grow old.

It seems that it is the same with the quality of a phone call. From the early days of the switchboard to calls over the cellular network, the phrase “can you repeat that? I couldn’t hear you” has been commonly heard over the years. And so has the emphasis on improving voice quality accompanied the advances made in telephony communications.

One-Fish-Two-Fish-Red-Fish-Blue-Fish-by-Dr-Seuss

Source: One Fish Two Fish Red Fish Blue Fish, by Dr. Seuss

This is no less true today with Voice over IP (VoIP) networks. Perhaps the greatest enemies of a quality call over VoIP networks are delay, jitter and packet loss. Network experts invest great efforts in fine tuning their networks so as to minimize the negative effects of these factors. In a recent post on this blog entitled “Voice is Coming to LTE”, Amir Zmora pointed out that in his experience in speaking with service providers that are already invested in VoLTE and interconnecting with other networks, it was clear that voice quality and QoE are their main concerns.

VoIP traffic may traverse wireline, WAN, cellular or wireless networks. Wireless traffic in particular is inherently inconsistent and the effects of delay, jitter and packet loss, if not handled, can seriously impair the quality of a call. Wireless networks were designed first and foremost for data applications. But in data focused applications, the most important thing is for the payload to arrive complete, how fast it gets there is less important. Thus, compensating measures can be implemented to guarantee that requirement. However, while these capabilities ensure the arrival of the packets, they also increase delay and jitter. And while delay for data applications is acceptable, in the case of VoIP the delay may be intolerable resulting in someone saying “I didn’t catch that, come again?” or just dropping the call altogether.

As most VoIP entities in the network (session border controllers, gateways, ATAs, IP Phones, mobile clients, etc.) were designed to handle wireline, and not wireless impairments, they have a hard time handling (without help) traffic emanating from wireless networks. To get around the problem, AudioCodes has implemented special built-in tools inside its Session Border Controllers. By placing the SBC with these tools between the wireless network and any other network (wireless, wireline, cellular, etc.), the impairments from the wireless network traffic can be managed and reduced dramatically to allow for an end-to-end quality call and prevent someone from saying, “I cannot hear your call. I cannot hear your call at all!”

Want more information?

Click here to download a White Paper in which you will learn how built-in SBC tools such as an adaptive jitter buffer, transcoding, redundancy, trans rating and quality-based routing can each play a major role in significantly enhancing QoE. Furthermore, when taken together and given the ability to fine tune and balance between the variables, they can be truly powerful.

Cloud

Who is afraid of the cloud?

[Post is better viewed on the blog Website]

Cloud“The Cloud” – everyone is talking about it. Studies, market reports and analysts refer to it as the “next thing” and as the opportunity that communication service providers (CSPs) must not miss. Well, it is not so easy!

Revenue opportunity for the service providers

There is no doubt that the telecom market is changing. The increased competition and the commoditization of traditional telecom services have negative impact on the CSPs revenues leading them to evolve beyond network connectivity and seek new revenue opportunities.

The good news is that the cloud trend that we are seeing for some years in the market has reached a point where CSPs can create “real” business value. According to Informa’s Telecom Cloud Monitor (http://www.informatandm.com/cloud-monitor/), the number of CSPs selling Cloud services has increased from around 60 in 2009 to about 230 in 2012 and there is a consistent growth in CSPs cloud spending.

CSPs active in cloud services by region

Cloud services allow the CSPs additional revenue streams with new value propositions that they can offer. For example, a CSP can leverage its key strengths in communication technologies to offer hosted unified communications (UC) services that combine data, voice, security and more, but at a lower cost as compared to on-site platforms. Another example is the provision of cloud applications such as business sales automation, invoicing and billing, and storage and backup in the cloud.

Why should businesses move to cloud-based services? Well, there are some good reasons for doing so including cost flexibility, business scalability and simplifying communication services.

Can we trust the cloud?

How can the CSPs deal with customers’ fears of the cloud? These customers, most of them being small medium business (SMBs), are scared of putting key business functions into the cloud because if something goes wrong, they fear it could stop their business in its tracks. So, CSPs need solutions that will enable them to allay these fears.

We need to remember that CSPs have a unique advantage over other cloud players such as Over-the-Top (OTT) providers, given their existing data and voice communication networks. This is the biggest asset differentiating them from others. Using their existing managed networks, the CSP can guarantee end-to-end Quality-of-Service (QoS) that is critical for SMBs that need to perform at an enterprise level. The CSPs are known for their existing secure networks, providing them with a strong brand advantage when dealing with SMBs that are concerned with putting their sensitive business data in the cloud. And of course, CSPs have the advantage of existing local footprints and existing customer relationships.

The SMB customers that move to the cloud, in most cases do not understand technology and products, but they do require solutions and services. From the CSP perspective, the most critical factor for the SMBs will likely be the quality of experience (QoE) – keeping customers satisfied and avoiding churn. As mentioned above, CSPs are in a unique position given their existing managed communication network including the on-premises access equipment. The on-premises equipment is the demarcation point to the CSP data and voice cloud services. Without QoE assurance in this equipment, it will be extremely difficult for the CSP to sell and deploy reliable and trusted cloud-based services.

SMBs and Cloud

Protecting the business

As part of my work in AudioCodes I meet regularly with leading CSPs and hear their perspectives regarding their SMB customers’ needs when moving to cloud-based services. One of the things that they are most wary about is the business continuity, meaning, how can they make sure that the data and voice cloud services are always available? Consider the implications of an unreachable business, even if it is just for few minutes. Of course this will reduce customer satisfaction and eventually cost the business money. Or consider the example of a small insurance company that cannot access to its customer data base in the cloud and how bad that would affect the business customer support service.

In the real world, failures happen, and yes, there will be cases when the voice or data services in the cloud will be unreachable. So the question is how can we protect ourselves from such a scenario?  And the answer is: Backup, Survivable & Resilience.

SMBs and Cloud Appliance

One solution is to use business routers with backup and survivability features. One of the great things about such a product is that it allows the CSPs to allay their customers’ fear of the cloud and provide them the confidence they need to place their key business functions in the cloud.

The approach is to use multiple WAN interfaces, backup PSTN interfaces and suitable software. With redundant WAN interfaces, you can make sure that in the case of a connection loss to the primary WAN the router will auto-switch to the backup network (for example the 3G/4G mobile network) assuring the SMB customer’s an “always on” Internet connection.

The router also ensures that critical business telephony services will continue to operate in the case of a connection loss with the hosted PBX. This is done using unique software features that will auto route the outgoing calls to the backup PSTN and will maintain internal business telephony operations.

So, the next time you are considering cloud-based services, ask yourself, are you protected in the case of a connection loss to the cloud? There is no reason why you shouldn’t be.

Image Credit: Flickr user Karen Ka Ying Wong