Posts

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.

forcing vendors to enter a cat-and-mouse game

Voice is Coming to LTE

[Post is better viewed on the blog Website]

 Back in 1999, when 3G was still a questionable dream IMS started to take root as an architecture for mobile services. It was adopted by the 3GPP and later on also by 3GPP2 and other organizations and forums. Standardization work went on for many years resulting in continuous releases of standard versions forcing vendors to enter a cat-and-mouse game.

forcing vendors to enter a cat-and-mouse game

The adoption of IMS was slow and disappointing

There are many IMS deployments today but IMS didn’t deliver on its promise. While vendors and service providers were busy fighting in the standard bodies, small start-ups came quickly to the market with advanced services and took the market by storm.

VoLTE is based on IMS and is defined in IR.92 and IR.94. In a nutshell, it defines Voice, SMS over IMS (IR.92) and Video (IR.94) over LTE networks.

So what is all the fuss about VoLTE?

The answer to that lies in the eyes of the beholder.

LTE networks are being deployed by hundreds of service providers worldwide. Once LTE coverage is ubiquitous, there is a lot of sense for the service provider to move away from circuit switched (CS) voice to VoLTE, as in a few years it will eliminate the need to continue supporting the CS network, thereby reducing OPEX.

Additionally, higher quality end-to-end voice will be possible as VoLTE supports HD voice and includes features for resource reservation as well as other important features such as security.

From the end user perspective, in addition to the higher quality voice and security that comes with VoLTE, longer battery life will be possible as the need for dual LTE & CS connectivity of the phone will be removed.

Reality check

Learning from the past, there are 3 fundamental challenges service providers and vendors will need to solve.

Time to market

Service providers have waited for technologies to become stable and for standards to become fully ratified. This stopped them from launching advanced services, leaving the door open for OTTs.

Interoperability

The reality is that service providers currently providing VoLTE services are not all doing so the same way. Different capabilities and scenarios are supported by each service provider. This results in the need to verify each device and server before it is deployed on their network and vendors are required to make modifications in order to pass this certification process. Given this reality, there is a need to have a mediation element (SBC) between service providers, thus interoperability is theoretical… (did I say there is no point in waiting for everything to be perfectly compatible and ready?) Launch…don’t wait.

There are other networks out there

The service provider world is more complex than that of an OTT. The service provider doesn’t have the benefit of building an island. It needs to connect to older networks, enterprise networks and other service providers. This again brings up the need for that demarcation point that will mediate signalling and make sure voice quality between those networks remain good.

Speaking with service providers that are already invested in VoLTE and interconnecting with other networks, voice quality and QoE are their main concerns. Solutions for these concerns are provided through advanced audio processing done in mediation entities that interconnect between the networks.

Stay tuned for more on QoE in future posts on this blog.

Why is this important?

There are different opinions about the future of VoLTE and its chances to succeed. There is no doubt that secured voice calls using HD codecs are possible today using OTT. It is also clear that an OTT will not go this route, but in the service provider space VoLTE looks like a technology that will happen because:

  • It makes sense from an operational cost perspective
  • VoLTE integrates nicely into the service provider’s existing OSS/BSS systems
  • There are ways to downgrade the call to 3G/TDM when LTE is not available…SRVCC

Having said that, interoperability is a challenge. Service providers should assume there will be no 100% interoperability and standard support both on phones and servers. Certification of clients will always be required as well as demarcation points between networks as exist today in their VoIP networks.

Therefore time to market is more important than completing every item on the standards checklist.

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

Small Businesses - Big Opportunity

SMALL businesses, BIG opportunity

[Post is better viewed on the blog Website]

Small Businesses - Big OpportunityI recently read an article about the importance of small medium businesses (SMBs) and their benefits to countries’ local economies and wondered how this is reflected in local communication services deployed in those countries?

There is no doubt that VoIP technologies have changed the communications world and the way that Communication Service Providers (CSPs) do business. Still, looking at the SMB segment (I refer here to companies with more than 4 and less than 250 employees), it seems that out of a total of 75 million worldwide SMBs, only 12 million are connected to VoIP services and the rest are still using legacy TDM lines.  Clearly, there is huge opportunity here for CSPs as well as for VoIP equipment providers.

According to an internal analysis we conducted in AudioCodes, based on market research reports we expect that by 2017 the number of SMBs connected to VoIP services will more than double to 25 million with an average annual growth of more than 3 million every year!!!

Worldwide SMBs connected to VoIP Services

In the past, the needs of SMBs were quite modest in comparison to those of the enterprise. But this is changing – and fast. The communications needs of SMBs have grown far beyond a managed PBX and an Internet connection. The increasing awareness of the need for data and cloud services, together with the availability of affordable platforms, encourages SMBs to acquire advanced communication services that will help their businesses grow.

Win the SMB market with QoE Ingredients

When facing SMB customers, CSPs need to take into consideration that these SMB customers are limited in their budgets and do not have the technical resources as do enterprises. At the same time, CSPs understand that in order to succeed in the SMB space, they must offer a compelling service bundle for the right price, and probably, the most important factor will be QoE.

We need to remember that even if in most cases the SMBs let the CSPs manage their communication services, they are fully aware of the importance of these services and the critical impact they can have on their business.  Accordingly, they carefully evaluate these services when interacting with CSPs. SMBs expect their businesses to be always available, with no less than excellent voice quality and fast Internet service. They expect a productive environment for their employees with suitable and accessible data tools and they are very concerned about security. And, of course, the solution must be affordable.

Business Communications Needs

Faced with this significant opportunity, CSPs are challenged to provide SMB customers with the expected QoE starting with the on-premise business routers. Using the right business routers with features such as business continuity and consistent performance, will allow CSPs to deploy data and voice services with high QoE that will help them to capitalize on these opportunities.

More information can be found in the “Big Solutions for Small Business” white paper and at AudioCodes Multi-Service Business Routers Page (http://www.audiocodes.com/msbr)

 

Active Passive Networks Monitoring

VoIP Networks Monitoring Approaches: Which Way to Go?

[Post is better viewed on the blog Website]

As voice networks evolve into all IP frameworks and with the understanding that the organization’s voice networks become dependent on many factors which are not directly correlated with the voice network itself, it becomes clear to any IT organization that proper monitoring tools are required in order to maintain the quality of experience of the end users. But what is the right approach for monitoring the voice network?

Active Monitoring

Active Passive Networks MonitoringIn the past, in order to properly conduct end-to-end quality monitoring, you had to incorporate testing equipment into your environment, inject VoIP traffic on top of the existing VoIP network, collect traffic statistics and then start troubleshooting the problem. This method was known as “Active Monitoring”. But this approach had some significant drawbacks. It could not, for example, track existing calls running in the network. If an end user complained about a problem, there was very little that could be done to manage this complaint effectively.  Another problem is that you had to install additional hardware in the locations in which you wanted to test the traffic. In large-scale deployments, this could render the costs of a monitoring solution unacceptable. Active call generators would have to be moved from one place to another which would clearly cause a delay in troubleshooting and resolving the problem. To illustrate, if there was a complaint in New Jersey but the call generator was currently placed in Boston, the call generator would need to be shipped to New Jersey before the troubleshooting process could begin. On top of that, the extra probe adds more traffic to the underlying network which tacks on another factor of uncertainty. Will the existing network traffic running the call generator be affected by this addition? Will it further worsen the existing problems?

Passive Monitoring

It was clear that an alternative means of monitoring was required and this led to the introduction of passive monitoring. “Passive Monitoring” is a method in which a network is configured to mirror ongoing traffic to a passive probe which then looks at the entire set of the packet stream and can provide statistics based on the collected information. This approach clearly solves the problem where there was a need to check a specific end user’s complaint. It also does not introduce additional traffic load to the network. However, there are still some problems with this approach. Hardware probes still have to be placed in each location that needs to be monitored. For large scale enterprises (and in the case of New Jersey vs. Boston example provided above) this remains a problem. Additionally, you still have to configure the IP elements in the network such as switches and routers to mirror the traffic to another location. What about a scenario in which the entire set of the physical ports on the switch is already exhausted. Another switch might be required just to do the monitoring!

 

Probeless Monitoring

In the last few years a new solution trend is catching on fast. The new solution is similar to the passive approach but takes it to the next step for better monitoring. The idea is that each of the active network elements provide statistics to a higher management layer which can then provide a service level view as well as statistics with very fast troubleshooting schemes. With this approach, there is no need to add additional hardware to the network. There is also no need to mirror the traffic from the existing switches and routers. You only need to be able to interface with existing provided interfaces of the network elements to receive an end-to-end view.

 

This would appear to be the ideal solution. But is this really the case? Well, it is no doubt a major improvement over past solutions but there are still some issues that remain. Firstly, there is the issue of how you can get a full end-to-end view with heterogeneous network components? Secondly, there are some situations where passive monitoring cannot help and Active Monitoring is preferable. For example, if no traffic exists on the network, how do you know if there is a problem? You want to be sure that once a call is placed on the network that it will work. By the time the end user complains, it is too late. Active Monitoring can validate that calls from specific locations will indeed work. Also, the active monitoring solution can validate capacity planning. The IT CIO planned for a certain network capacity, but how can he/she be sure that the traffic load will flow without problems? Here, Active Monitoring is a useful methodology.

 

The Combined Approach

What really is required here for an IT organization to effectively monitor the quality of the voice network is a combined approach of Active AND Passive monitoring. What is needed is a comprehensive quality monitoring tool (such as AudioCodes SEM) that passively integrates with all of the company’s voice network elements as well as with UC applications such as Microsoft Lync. Such a tool can provide a full end-to-end monitoring view of network elements (IP-Phones, gateways, SBCs, soft clients, etc). Additionally, active probes can be embedded in the network in order to generate synthetic VoIP traffic according to predefined capacity loads. In this way, administrators can make sure that the deployment meets the requirements of the planning. The comprehensive quality monitoring tool, which integrates with both the active network elements and the embedded probes, will be able to simultaneously capture both real time and synthetic traffic, allowing for quick root cause analyses of voice network problems and assuring that the voice network can manage the traffic for which it was designed.

Moving WebRTC Into Your Network Through the Front Door

Moving WebRTC Into Your Network Through the Front Door

As part of my work with WebRTC, I get a chance to speak to different types of companies about their WebRTC plans. When speaking with companies that have existing VoIP products and services, the conversation usually moves to how WebRTC should be added to their offering, what the additional service benefits are and how to architect the solution. The typical requirement is to leave the existing deployment untouched and bridge WebRTC into the existing network through some sort of a GW. Where should the logical function of the GW be located and what should the network architecture look like are usually the questions debated. To answer them, I decided to write this post.Moving WebRTC Into Your Network Through the Front Door

Image credit: Muhammad Mahdi Karim

To demonstrate the consideration points and options, I will use an example of a contact center. For the sake of this example, let’s take a contact center that has both PSTN lines as well as SIP Trunks from a service provider. All traffic inside the contact center is via SIP where some of the agents are working on premise and others are home agents who are “called in” for handling contact center peak traffic.

 

Architecture Options when Adding WebRTC

In my discussions with customers and partners who are looking to add WebRTC into their existing networks, the architecture alternatives considered were:

  • A dedicated GW
  • Adding a WebRTC interface to their current core server
  • Adding WebRTC through an SBC

Before and After WebRTC

BeforePre WebRTC Contact Center Connectivity

  • Traffic comes from a service provider over SIP trunks or PSTN
  • All traffic in the contact center is SIP
  • Home agents are connected over IP-SIP but this is done in a secured and controlled manner
  • The contact center core server is placed inside the contact center network. Security is handled by other elements so it is protected from denial of service attacks, call fraud and other security vulnerabilities
  • Calls are using G.729 or G.711. Transcoding, if required, is handled in the contact center network

 

After

Adding WebRTC into the game creates new requirements and a new type of traffic source. With WebRTC, users browsing the website of the company serviced by the contact center, can call in directly from the browser. Their traffic runs over the Internet directly to the contact center.

WebRTC includes 2 voice codecs: G.711 and Opus. These are the codecs that come within the browser. If the intention is to eliminate the need for download, calls must be initiated using one of these 2 codecs.

Since G.711 is not built for running over the open Internet as it doesn’t include resiliency, it is beneficial to initiate the calls with Opus. The optimal approach would be to run Opus end-to-end from the browser to the agent but in cases where this is not possible, it is best to keep Opus on the open Internet leg and transcode when getting into the contact center network.Alternatives for adding WebRTC to the Contact Center

  • The contact center is required to have a “leg” in the public Internet domain
  • Quality of service is not managed. Even though in many cases the quality is good, supporting SLA requires the capacity to manage and monitor quality of experience (QoE)
  • Supporting Opus requires either adding a new intensive computing transcoding function or adding Opus to the agent’s client

 

Alternatives Comparison for adding WebRTC to Contact CenterThe comparison above doesn’t relate to any vendor specific product but rather looks at common functionalities of such products. Given this, the following conclusion should be viewed in context of the actual functionality supported by the specific products considered.

The comparison shows that in the case of the contact center example in this post, adding WebRTC to the existing internal contact center server will yield high risk and therefore, it is not a recommended alternative.

The selection between a pure GW and an SBC would depend on priority focus. If security and QoS are of high priority, the comparison leans towards the SBC alternative.

Breaking Loose from MPLS

Breaking Loose from MPLS? You Better Keep an Eye on Your Network

Breaking Loose from MPLSDid you ever hear this answer when complaining to IT about a bad call experience over a VoIP network?

Try to make that call again and if things go bad yet again please let me know

Enterprise telephony networks of the past were rather simple from a quality assurance perspective. The move to IP was gradual, typically starting within the enterprise via the move to IP PBXs in the branches, adding inter-branch connectivity over IP and later switching to full IP also on the access side. This was typically done using MPLS lines that provided quality assurance but at a high price.

Quality of Experience (QoE) is critical for enterprise communication networks. I spoke about this topic from a bit of a different perspective at the last Upperside WebRTC Conference and shared the presentation as well. The move to an all IP architecture introduced quality challenges as enterprise networks are complex with multiple sites and a need to connect efficiently between them. Challenges are magnified as enterprises break loose from MPLS chains and move to unmanaged IP networks. Issues that arise from such a change span all VoIP disciplines from call control through media routing to codecs. This makes effective troubleshooting of telephony problems and keeping a consistent good quality of experience, a hard nut to crack.

Driving blind through the network

If you would ask an IT manager at any given point in time the status of his VoIP network, he would be able to give basic statistical information about call activity, packet loss and bandwidth utilization. But now comes the tricky part – understanding what the user experience is like or why this experience was bad on a specific call. The typical answer to such a complaint about call quality is similar to the quote at the beginning of this post but the thing is that when making the call again, the problem usually wouldn’t happen.

By the time the problem does happen again, too much time has passed, context is lost and IT is back to square one trying to figure out what happened and what needs to be done to fix it. VoIP is an application that runs on top of the IP network. For monitoring and resolving VoIP problems, IT needs a proper “pair of glasses” built specifically for the nature of VoIP applications and networks.

Fundamental requirements for effective network monitoring

In order to improve user experience, it is required to understand the root cause of the problem and act upon such findings. A few fundamental capabilities are required in order for a monitoring system to provide this capability. Basically, it boils down to a holistic view of the network and aggregation of calls statistics of different interfaces. Monitoring a single call and acting upon that is not going to solve the root cause of the issues you have in your interface between office A and office B. But looking at the overall flow of calls between locations will enable you to identify network issues.

Take as an example QoS marking mis configuration – such an issue may result in sporadic quality issues and identifying the root cause of the issue will be possible only once the monitoring system has identified that this happens only on one specific media route in which a router is breaking the QoS marking.

It’s clear that regular network monitoring tools will not be helpful in diagnosing the problem and that a proper pair of “glasses” that can find network misconfigurations which result in bad quality of experience is required.

Based on this, the fundamental requirements from a monitoring system would include:

  • IT time saving – Help in finding the root cause of the problem in a few simple clicks
  • Real Time analysis – Showing what really happens in the VoIP network when the problem occurs. It is great to be able to just look at the screen and see what exactly is happening throughout the entire VoIP network.
  • Notifications – Getting alerts on real problems in the VoIP network before they are reported by a user, or worse, being escalated to higher management.
  • Trend statistics – This relates to that holistic network view that allows for identifying issues over time and keeps quality issues in context. Good examples of this are quality issues that happen repeatedly while another activity is taking place on the network. Such an “activity” can be a backup system running high network traffic or a user downloading large files.
  • Monitoring the call control – analysis of the media is not enough as many cases of bad user experience are related to call control issues such as dropped calls and incorrect routing of calls that result in call establishment failure.
  • Network probes – In order to monitor the network of a distributed enterprise you need to have a probe in each location that will collect and report network statistics and quality information.
  • Demarcation point in each branch – The demarcation point located at the edge of the local network will allow for the isolation of problems and assist in understanding if the root cause of an issue is on the enterprise network or related to the provider of the access or telephony service.
  • Remote access & visibility to all sites – Once problems are identified, you need to be able to act upon the findings and make changes in remote locations.

 

In conclusion, enterprise real-time communications solutions comprise multiple parties, from the access providers through telephony service providers to server and end user equipment. Monitoring the network, understanding the root cause of issues and changing what is required to be changed in order to avoid further quality issues, is a difficult task. The road to achieving this goal runs through both minimizing the number of vendors involved and using a monitoring solution that has a holistic view of the entire network and of each branch.

At AudioCodes, we have been working with such cases for many years. As a company that started from the voice codec level and grew to become a complete one-stop-shop for VoIP communication, we understand the concerns and issues enterprises are experiencing when moving to an all IP environment. For that reason, we have developed a Session Experience Manager solution (SEM) that is part of our One Voice offering.

Feel free to relate your stories about quality issues and conclusions from these cases in comments to this post.