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.

REST API for SBC Configuration

Why REST APIs are Not Yet Another SBC Configuration Interface

[Post is better viewed on the blog Website]

REST API for SBC ConfigurationFor most of us who grew up in the telecom industry, management protocols like SNMP, TR-69, and Command Line Interface (CLI) have been for many years the only management protocols we’ve known and used on telecom equipment.

Telecom’s bigger (but younger) brother, the Internet, has developed its own set of management interfaces (APIs), mainly SOAP and REST.

Well guess what? Similar to what happened to some telecom services that were replaced by Web apps (for example SMS replaced by WhatsApp), so are legacy telecom management protocols being replaced by Web management protocols, led by REST.

But REST is more than just another way to manage telecom devices. Being a dominant API in Web technology, REST serves, among other things, as a bridge between Web applications to telecom devices which were previously isolated in their own ‘telecom’ domain.

Linking these two worlds yields new services which were not previously possible.

For example, today an SBC can be connected to a CRM web application (i.e. Salesforce.com) and allow an employee to place a call to his customer by clicking the contact’s name on the CRM web GUI (this may also involve WebRTC).

Some words on how REST works. REST (or RESTfull API as it is sometimes called) is used to manage and read the status of a remote device.  It uses HTTP as its transport layer and in most cases the message payload uses ‘JSON’ structure.

JSON is a human-readable format, which makes it possible for anyone to inspect these messages.

Besides the great synergy that REST brings by linking the Web and Telecom worlds, REST in itself has important advantages over the legacy Telecom management protocols that make the development process easier for the 3rd parties integrating with the API. Unlike SNMP and TR-69, REST is, as said, human-readable. Thanks to HTTP, REST easily traverses firewalls – a problem which SNMP and CLI may face. REST also does not require identical schemas (data structures) to run on both managing and managed devices in order to talk to each other, which simplify its maintenance. REST is also secure as it can run over HTTPS while security on the legacy protocols is complex.

Lastly, REST is a stateless API unlike CLI (which is both statefull and unstructured). REST statelessness makes it easier to implement.

AudioCodes, which has always been a firm believer in open standards, is investing heavily in REST. Our soon to arrive next major SBC release, will have an impressive set of REST APIs with which our partners are already working to create innovative new applications. Stay tuned.

Redundancy & High Availability

High Availability Redundancy for All

[Post is better viewed on the blog Website]

The Need for High Availability

The need for businesses to remain on-line at all times, if the connection to the service provider or on premise equipment should go down, is a critical one. And it is critical for all businesses, large and small alike.

In VoIP networking, the ability to always keep the network up and running is called High Availability (HA) and it can mean several things. For one, it means survivability. If the WAN connection (SIP trunk) to the service provider goes down, the customer needs a “Plan B”.  This is typically accomplished with a Session Border Controller (SBC) deployed at the enterprise, playing an important role in continued phone connectivity and routing at the customer site. It also can mean resilience. Here, the calls at the customer will find their way out of the local site to their destinations via alternative channels. This can be via PSTN fall-back, via GSM connection or even via a connection to a back-up second SIP trunk.

Redundancy & High AvailabilityAnd then there is redundancy where fully redundant networking infrastructure is used, eliminating single point of failure risks. With VoIP networking this would mean there are two SBCs deployed in an active/standby configuration. In normal operations, the first SBC does everything while the standby SBC is only synched with the first one. However, if for whatever reason the first SBC goes down, the second one takes over and all the active calls now go through it, ensuring that no active calls are dropped. User registration is synched between the two devices and a transfer to the standby SBC, seamless to both the network and to the users, occurs.

Increase in HA Demand for Medium to Small Businesses

Survivability and resiliency tend to be features provided in networks of all sizes. However, redundancy, for many vendors, seems to be reserved for only the larger carrier and enterprise networks, those with over 600 sessions. To handle requirements for High Availability redundancy for small to medium businesses some SBC vendors offer their customers over-sized carrier-class SBCs. This mismatch forces customers to deploy SBCs which don’t fit neatly into the enterprise environment, as they are more expensive, have unnecessary features on the one hand and may be missing other features necessary for this environment on the other.  (We call this “Going duck hunting with a Howitzer” – overly complex and in the end, not very effective).

At AudioCodes, we have witnessed a sharp increase in demand for High Availability Redundancy in small to medium businesses.  Perhaps these businesses have reached the conclusion that even in these smaller business environments they simply can’t take the risk that something will take down their network. AudioCodes has moved to satisfy this demand from the smaller businesses by installing High Availability redundancy in the Company’s Mediant 500 and 800 SBCs in addition to the higher-session SBCs.

(BTW: no ducks were harmed in the writing of this article)