Posts

SIP Trunk

The SBC: A VoIP Network’s Best Friend

[Post is better viewed on the blog Website]

The Move from TDM to SIP Trunking

SIP TrunkI recently participated in an interesting webinar hosted by NoJitter entitled Real World SIP Trunking Advice: How IT Managers Seize the Opportunity and Avoid the Pitfalls. The webinar focused on the increasingly popular trend to move to SIP Trunking from legacy TDM.  The webinar highlighted research by Forrester which pointed to the fact that while only some 25% of companies have moved over to SIP Trunking so far, the move to SIP Trunking is indeed the future trend and will increase in the coming years.  The move is inevitable as it will save businesses a considerable amount of money, including dramatic reductions in telephony costs by moving to VoIP. And the key ingredient to the success of the move over to SIP trunking is the Session Border Controller (SBC).

The Necessity of an SBC

Theoretically, SIP trunks can connect to the existing IP-PBX without the need for an SBC. However, not using an SBC can lead to a whole array of issues which need to be taken into consideration.  For example, SIP implementation variances can lead to interoperability issues across multivendor systems and service provider networks.  Delivering high voice quality by minimizing packet loss, jitter and latency are also issues that need to be handled. And finally, the vital issue of security must be taken into account as well as SIP trunks are exposed to security threats. Conventional firewalls are not designed to secure VoIP traffic from denial of service attacks or toll fraud.

All of these issues are handled by the basic functionality of the SBC which includes: Security (encompassing such features as providing a VoIP firewall, topology hiding, encryption, and protection from attacks such as denial of service and call fraud); Connectivity (including SIP normalization, NAT Traversal, voice mediation and transcoding, DTMF and Fax conversion); and SLA and Quality of Service. Additionally, the SBC ensures business continuity by minimizing potential service interruption due to call spikes, power outages, service failures, loss of connectivity and natural disasters.

(For more on the role of SBCs, see our previous post by Amir Zmora, Who Needs an SBC Anyway?)

SBCs Handle Unique Challenges Facing Large Enterprises

SBCs are indeed very powerful devices that provide a plethora of services to the enterprise or service provider on whose network they are deployed, and they play a major role in the move to SIP Trunking. This is especially true for large enterprises which have their own unique set of challenges that go beyond the basics, challenges that are also well met by the SBC.

Large enterprises tend to have several major data centers and many geographically dispersed branches. These branches many times have different PBXs, different technologies and different network hardware, and they all need to talk to each other.

These large enterprises will face challenges managing their VoIP networks. Here are some examples:

  • Different branches may be using equipment from different vendors, for example, from Cisco, Avaya, Microsoft Lync and others. Through mergers and acquisitions, large enterprises may have acquired different systems that are now incorporated into the larger network and have to be managed differently.
  • The organization may be going through a migration from one technology to another (moving from TDM to SIP Trunking, for example) but still needs to interoperate with its legacy equipment.
  • The enterprise cannot afford down-time on the network and must ensure the survivability of the network in the case of the loss of WAN connectivity to the Service Provider.
  • IT Administrators would ideally want to see all the alarms monitored on the network in a single location, aggregated and prioritized, rather than have to go out and get them from different systems.
  • Because large enterprises deploy complex networks with a number of SBCs and Gateways, sometimes with different PBXs and IP-PBXs in the various branches, they are faced with complex routing challenges for their VoIP networks.
  • And more…

(For more information on the opportunity of VoIP for small businesses, see our previous post by Itzik Feiglevitch, Small Businesses-Big Opportunity)

 A VoIP Network’s Best Friend

More and more IT administrators are recognizing the power and value of the SBC on their voice networks. In their March 2014 Enterprise Session Border Controllers Quarterly Worldwide and Regional Market Size and Forecasts: 4Q13 focused on the enterprise, Infonetics Research reported that 2013 SBC revenues rose 42% over the previous year and they projected revenues to continue to rise at around 12% annually through 2018. Infonetics states that the primary driver for growth for SBCs is the adoption of SIP trunking services (no surprise), and while most sales are currently in North America (76% of total sales in 2013), other regions are expected to post growth as well, especially in Europe, where the adoption of SIP trunking is accelerating.

Clearly, large enterprises with complex VoIP network deployments face considerable challenges. However, the SBC provides tremendous functionality that can address these challenges well. As the move to SIP Trunking continues to gain momentum, more and more IT Administrators are sure to discover that the SBC is their VoIP network’s best friend.

Image credit: Flickr user Christina Quinn. Modified by AudioCodes under Creative Commons licensing

The Value of Voice

Make it Short, it is Expensive

Determining the value of communications

[Post is better viewed on the blog Website]

Mothers-in-law are a sensitive subject. Anyone who has a mother-in law knows this very well.

Now, don’t get me wrong. Most people would probably envy me for mine. She got into this post because she is a natural reserve for technology of the 60-70’s. She made a conscious decision to remain planted back in those days in many areas, technology is just one of them. It’s a long story and this isn’t the best place to go into details about it J. Last week I was in Spain with my wife trekking in the Pyrenees and our kids were left with our extended family. Two days during the week were with my mother-in-law at our house. When I called and my 6 years old son picked up the phone he started waffling his usual nonsense. In the background I heard my mother-in-law saying to him – “make it short, this is a very expensive call”.

The value of voice goes down to zero

This is something I heard many years ago and one I use myself. But this statement needs to be placed in the right context. When I call from my vacation, I have many means of making a free call or a call that is so cheap that practically puts it into the “free” category. My son can waffle for as long as he wants. I can call through a mobile application (called Bphone) provided by my local service provider that takes my home number with me and allows me to make calls from anywhere over WiFi at the cost of a local call, as if I was calling from home. This happens to be an application AudioCodes has provided Bezeq (the local service provider) for this service. I have plenty of other options for calling PSTN using Viber, Skype… or the AudioCodes enterprise mobility application. All these allow for calls from anywhere for a free/flat rate to a very low cost.

But this doesn’t mean that the value of voice goes down to zero. Voice is still the #1 revenue source for service providers. It has value for consumers and surely has value for enterprises, value that is far more than the call itself. There are services attached to calls in the enterprise environment.

A good post written by Yossi Zadah is scheduled for release next Monday that takes a look at the value of voice calls through the prism of call toll fraud, so stay tuned.

The value of communication is determined by the service in which it is embedded

The Value of VoiceThe value of voice as well as video, presence and messaging, is not in simply connecting such sessions but needs to be viewed in the context of the service in which it is embedded. If voice/video communication is embedded in an insurance company’s self-service website where a user can speak with an agent when running into issues purchasing his insurance, the value of the call is not the amount of cents it costs but rather the fact that the deal was closed instead of the customer going to the competitor. There is a multitude of examples of similar and other cases such as remote learning and group collaboration. In all these cases, the value of the call is the cost saved or the revenue earned. The value perceived by the provider of this specific service is higher than the value the Communications Service Provider (CSP) receives for the call. Therefore, packaging the calling service in a way that is easy to embed into other services will allow the communications service provider to extract more value from it. This naturally leads us to the web and to WebRTC.

WebRTC as a catalyzer

WebRTC makes communications ubiquitous across web services. It renders the world of VoIP communications accessible to web developers and not only to VoIP experts. WebRTC is a catalyzer for communication revenue as it allows combining communications with web services. Moreover, it allows connecting these services with the existing enterprise communications platforms through SBCs that reside within the enterprise domain or in the cloud. With WebRTC, communications become a web feature that allows for the increase of conversion rates and revenue from web-based services and therefore, its true value becomes the value of the service and not of the call itself.

Returning to the phrase “The value of voice goes down to zero” I would coin a new phrase “The value of voice is equal to the value of the service in which it resides.

What is your view on the value of voice? Feel free to express your views and comment to this post.

Who-needs-an-SBC-Anyway-Thumbnail

Who Needs an SBC Anyway?

[Post is better viewed on the blog Website]

In the early days of SIP, I was working on VoIP protocol stacks at Radvision. As part my role there I used to attend many of the IETF meetings and SIPit interoperability events. The standards where the holy grail and we were a bit naïve in assuming that everyone would be implementing the standard and nothing but the standard…and networks and products would interconnect easily.

The SBCs Come to life

In those days, almost 15 years ago, new startups that focused on something they called a Session Border Controller (SBC) were coming to life. Later down the road of VoIP deployment, more established companies adopted this concept.

I remember a panel at one of the VON shows in which I came out against this trend. At the end of the day, I said, every single SBC function is handled by the standards. As long as the VoIP community will follow the standards, life will be good and simple.

Reality check

I guess it is needless to say that the world of VoIP is more complex than simply implementing the standard. The reality is that networks and products usually don’t interwork without a special effort to make this interworking possible. There are 2 fundamental reasons for this:

  • Standards are complex, very detailed with multiple options, and many times companies interpret them differently
  • Companies want to add their special secret sauce into their products and sometimes, due to technical or commercial reasons, they implement some of the functionalities in a proprietary manner

Regardless of the reasons this is the reality. The naïve position of the past didn’t pass the reality check of real life.

Who-needs-an-SBC-Anyway

The business communications angle

VoIP is deployed in many enterprises and service providers’ networks, yet there are still many enterprises and SMBs that are not connected to VoIP services. Taking a closer look at those already using VoIP in the enterprise or receiving such a service from their service providers, we see several common characteristics:

  • Not all branches use the same PBX. This is due to acquisitions or changes along the life of the network that were not implemented across the board
  • A hosted service was added servicing some of the branches, requiring the connecting of the on-premise PBX and phones with the hosted service network
  • A unified communications service such as Microsoft Lync was added in addition to the existing telephony system requiring the connection of the 2 networks together
  • Survivability needs and local PSTN termination require an on-premise “box” to provide these capabilities

Each one of the points above introduces complexity and a mix of standard and proprietary (or as some vendors call it, “SIP like” or “in the spirit of SIP”). As this phenomenon is the reality of today’s business networks, a smart mediation box is required to connect between the different elements and support these requirements.

What is special about the SBC that makes it the “Swiss Army Knife” of VoIP?

An SBC is like a Swiss Army Knife as it handles many functions. It is well aware of the specific environment in which it is deployed and typically has a flexible configuration that allows adapting it to the specific deployment environment. On the other hand, SBCs are also known for complex configuration due to their complex functionality. As such, a configuration wizard that contains various vendor product profiles for automatic and easy configuration of the SBC for specific deployment scenarios comes in handy for simplifying SBC configuration.  

A typical SBC would have the following functions:

Mitigation & connectivity – connect between different PBXs and different hosted services, connectivity with different SIP trunk providers.

Security – detect security threats such as denial of service, call theft and eavesdropping and protect the network from them. The SBC may also perform encryption/decryption functions to force a policy requiring all outbound traffic to be encrypted.

Quality of Service – the SBC monitors call quality, reports on issues and may enhance quality through media manipulation

Routing & policy enforcement– making sure calls routed based on the enterprise policy-based on user identity & privileges, call termination cost, quality requirements and network conditions

Regulatory compliance – route calls to recording services

The list of functions above is a general and non-exhaustive list. Naturally, there are different functionalities required depending on the type of the SBC, be it an access SBC or an enterprise SBC.

In conclusion, if in the past there was a debate about the need for an SBC, today SBCs are found in most deployments, on-premise as well as in hosted services, providing functionalities such as security and resiliency. Moreover, the SBC is included in many of the architectures defined in the standards.

Image credit: Flickr user Hiking Artist

 

all you need is cloud

All You Need is Cloud

[Post is better viewed on the blog Website]

all you need is cloudI recently read the post from Software Advice called 3 Ways to Keep Your VoIP Service From Going Down With the Internet by Don Sadler. Overall it, was music to my ears, hence the title of this post.

Many people fall in love with the concept that going cloud with your enterprise telephony system means the end of all of your telephony worries.

The reality is more complicated, however.

Don’t get me wrong, putting your enterprise communications in the cloud is the right way to go. Yet life is a bit more complex than pure cloud vs. pure on-premise. The grey area between them is what complicates things.

The misconception of pure cloud

Starting to use an enterprise communications cloud service would basically require the following steps:

  • Register for the service and pay with your credit card
  • Upload an Excel file with all users and extensions
  • Start talking

This would pretty much be all that is required for a greenfield, a one location business with a few guys that are using an application on their mobile phones for their business telephony operations. But what if you are an enterprise, large or SMB, with multiple locations and an existing telephony system?

In such a case there will be a few requirements that will complicate things. A non-exhaustive list of these requirements include:

  • Gradual migration to the cloud
  • Call flow optimization (e.g. when 2 users are calling in the same premise)
  • Cost optimization when calling to PSTN
  • Resiliency

Gradual migration to the cloud

Typically, IT will not pull the plug on the current on-premise system and plug in the cloud service instead. They would run a test on one site, then expand to a multi-site pilot and only after a few months make the switch. What happens during this pilot phase and how are the 2 systems connected?

Moreover, in some deployments, IT may decide to maintain the old system for a longer period.  This may be due to technical or business reasons. Supporting this requirement will typically be achieved by deploying an on-premise SBC that will connect the 2 networks and make this integration transparent to the end user.

Call flow optimization

In the pure cloud approach, when all you have on-premise are IP Phones or an application on your smartphone, for example a phone call from John to his colleague next door, Alice, would see the signaling going through the cloud.

How about the media?

Would it go directly between John and Alice or would it need to go all the way to the cloud provider and back?

The answer is… it depends.

There are various factors that will determine the media flow in such a case. The key requirement for the cloud provider to technically be able to enable direct media is to know John and Alice are located on the same network. This can be achieved by simply having one “leg” of the cloud SBC in the enterprise network, something that introduces a security vulnerability or through an on-premise “component” that will figure this out. In real world deployments, all of these options exist.

Cost optimization when calling to PSTN

Do you want all calls to the PSTN to go out from the cloud provider’s network or perhaps you have better PSTN termination agreements in some areas where you also have a local branch? Would you want to route calls to the PSTN in that calling area through your local branch?

Achieving this will require some extra routing logic and an on-premise GW in the branch office.

Resiliency

This brings us back to Don Sadler’s post that talks about resiliency requirements for hosted communication services. Resiliency will keep communications alive even if the cloud provider’s service goes down or if there is a problem with the company’s connection to the provider. Having an on-premise cloud appliance will ensure continuity of communications between extensions in the branch, calls to the PSTN and routing of calls through a backup Internet connection (e.g. cellular).

Enterprise Hosted Services Architecture

A typical hosted enterprise communication services architecture

Conclusion

If you are in process of architecting your move to the cloud, it is important to remember that as VoIP cloud deployments move from MPLS to non-dedicated lines over the Internet, the level of control in the hands of your cloud provider is reduced. As such, having an on-premise demarcation point becomes essential. Solutions that enhance cloud communication services are available on the market. Audiocodes, as part of its One Voice for Hosted Services, offers such solutions specifically for Broadsoft deployments as well as for other hosted VoIP and UC deployments.

Featured image credit: Paula Izzo
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.

Lync Conference 2014 Ran Inbar

Lync Conference 2014 – Smashing into a New Era

[Post is better viewed on the blog Website]

Lync Conference 2014 Ran InbarThe second annual Lync Conference is now behind us, this year held in the Aria Convention Center in Las Vegas and again a sell-out.  Themed “Coming Together”, the event was attended by some 1,800 end-customers, partners and Microsoft staffers.   Mecca for the Lync faithful, the Lync Conference is the place to be for Lync education, networking and a peek at coming attractions.

This year saw an increasing number of enterprise users, many sharing their experiences in moving beyond their early pilots to full implementations.  During AudioCodes’ private “Circle of Excellence” pre-conference event, we heard from a number of Lync network administrators about their successes and challenges in implementing Lync voice and conferencing across their enterprises.  Cargill, Amgen, Bally Entertainment and a number of other large enterprises all shared their Lync migration stories in great detail.  You can read a summary of the event by Brent Kelly, Consultant at KelCor.

We also took the opportunity to demonstrate our new 430HD and 440HD IP Phones along with our Better Together over IP functionality for Microsoft Lync.  Shown here, Ran Inbar, CTO Unified Communication for AudioCodes demonstrates the Better Together functionality to Matt Landis, a widely read blogger on the topic of Lync.

On the main keynote stage, Microsoft announced some key milestones for Lync with Derek Burney demonstrating the increasingly integrated Skype/Lync experience, the newly updated Lync client for Android tablets and a pre-release look at voice-driven “zero click” Lync client features.

Microsoft Lync Conference 2014 Gurdeep PallFollowing Derek, Gurdeep Singh Pall returned to the stage, announcing the end of the era of Unified Communications and the start of Universal Communications, bringing a consistent user experience across media types and devices. Gurdeep also demonstrated a web-based Jscript application, showing a somewhat un-realistic medical consultation experience, where a patient could hold a video call with a doctor.  (While the technology is very much realistic, in my experience, actually getting a doctor on a video call is highly un-realistic – they seem to be pretty techno-phobic.)

AudioCodes had the opportunity to share our experiences on a panel discussion on the Lync Ecosystem, sharing the stage with AT&T, Jabra, Unify2 and HP.  Challenging the “one throat to choke” argument, the panel dissected the benefits of the well established relationships between the large systems integrators, partners and enterprise buyers.

And finally, in an over-the-top spectacle, Microsoft’s exhibit featured a “product launch” cage where visitors could use a large slingshot to launch legacy telecom devices into a wall, aiming for a target with a gong in the center.  The occasional direct hit would fill the hall with the crashing sound, followed by cheers from the crowd.

Even if you missed the event, you can still participate in the conversation on http://mylync.lyncconf.com – Alan can be reached  via email at alan.percy@audiocodes.com or on Twitter @AlanDPercy

One Voice Operations Center

The VoIP Network Management Jigsaw Puzzle

Have you ever felt that your VoIP network management system is like a jigsaw puzzle requiring you to jump from one application to the other in order to complete a full cycle of handing an issue? Well, you are not alone. Meet Alice. Alice works in the IT department of a mid-size company with 3 offices in the US, 2 in Europe and 2 in APAC. This is what happened to her last week.

8:45am, Los Angeles

Alice gets a notification on her browser-based alarm system that there is a high call drop rate in the Boston branch office. She turns to the voice quality monitoring system to zoom-in on the problem.

She waits for the monitoring system to start, it’s a different GUI so it takes her a minute to find the information on that specific branch.

Since it looks like a problem that happened repeatedly over the last 2 hours, she runs a report to get the details of all calls dropped.

She flips back for just a minute to the alarm system to make sure these are really the calls for which the problem was reported. Alice then realizes that the problem has to do with one specific SIP Trunk that is dropping calls.

She must act fast. The Boston site executive was in touch with her from his mobile several times already. He and his team are about to go into a conference call with a customer and he is worried the call will fail.

Calling the service provider support line doesn’t look like something that will solve the problem for the call about to begin at the top of the hour. It is 8:53am and there is no time for support IVR and a call queue.

Alice decides to work around the problem and bypass this SIP trunk by configuring the branch SBC to route the calls through the Chicago branch over an MPLS link. She is still on the monitoring system so Alice now needs to switch to enter system with a different GUI, for the SBC configuration system.

OK. So I made up the story and invented my character Alice. But scenarios such as this one do play out every day for IT managers.

The multitude of independent management and configuration tools, each dealing with a specific task, is a major drawback in VoIP network management. You may think that this jigsaw puzzle is inevitable as each system comes from a different vendor or simply because each product has its related system even if they all come from the same vendor. But it doesn’t have to be that way.

But Gentleman, We Can Rebuild It

One Voice Operations CenterWhat if there was an all in one unified VoIP management suite? What if call quality monitoring, alerts and management of your network servers were all managed from one system? Well…that is exactly what AudioCodes One Voice Operations Center is all about.

The AudioCodes One Voice Operations Center is a suite of management tools providing full coverage of the entire set of actions required to manage a voice network in a Unified Communication environment.

It uniformly manages, monitors and operates the entire AudioCodes One Voice portfolio, including SBCs and Media GatewaysMicrosoft SBAs and IP Phones.

For example, in case of an enterprise using a Lync server, the One Voice Operation Center provides a complete view of the network voice quality, including Lync client to Lync client calls and Lync to PSTN calls. All in real-time. And if you need to fix a configuration, there is no need to go far. The same suite provides a provisioning interface to manage all your SBAs, SBCs and gateways.

Want to learn more? Come visit our booth #625 at the ‘Lync Conference’ to watch a live demo of our ‘One Voice Operations Center’.

AudioCodes and Broadsoft One Voice for Hosted Services

One Voice for Hosted Services Coming to Frankfurt

We have 2 major events this week both centered on AudioCodes One Voice solutions. While our team is setting up in Las Vegas for the Lync Conference and the many related activities AudioCodes will have there, I wanted to share with you some insights into our One Voice for Hosted Services event we will be holding later this week in Frankfurt, Germany, together with BroadSoft.AudioCodes and Broadsoft One Voice for Hosted Services

Bringing together service providers from Europe and endorsed by CEOs of both companies, the event will be a great place to learn about how to meet the challenges in launching and managing hosted Unified Communications services and how the combination of BroadSoft and AudioCodes solutions work to accelerate the revenue generation of such a service.

A Gartner analyst pointed out during a call we had before Christmas, that the on-premise equipment (or CPE) is one of the main pain-points for hosted services. The analyst noted two main challenges: (1) the many CPE vendors that the service provider needs to integrate and support, and (2) the high OPEX incurring at the stage of the installation at the customer premise. Not surprisingly, these very same challenges were mentioned by operators we met within the past few months, indicating that massive efforts and resources are invested in recurring on-premise equipment setup and operation.

AudioCodes One Voice for Hosted Services offering addresses exactly these points by helping to reduce the number of vendors and by the Zero-Touch provisioning this program offers to all CPEs. The offering includes a range of products covering all CPEs needs, from IP Phones and ATAs all the way up to routers and SBCs. AudioCodes Zero-Touch provisioning is designed to allow automatic configuration for all on-premise equipment without requiring a highly skilled technician to access and configure each device. The Zero-touch solution fits with the existing management by complementing the missing capabilities to reach end-to-end Zero-Touch provisioning. This mechanism will also fit both carriers and OTT service providers while adjusting to the specific network structure of each.

This week, in front of the major service providers in EMEA and together with BroadSoft, we will be presenting these solutions and demonstrating capabilities. In addition, Mr. Dean Bubley, one of the world’s leading experts on disruptive technology marketing, will examine enterprise opportunities for carriers, considering ways to find value in a rapidly-evolving ecosystem. He will also look at the immediate future and beyond, when customers will demand a better embracing of mobility, BYOD, embedded voice/video and new technologies such as WebRTC. I for one, am very much looking forward to hear what he has to say.

I don't gamble

I Don’t Gamble

The AudioCodes-Microsoft Lync angle

[Post is better viewed on the blog Website]

I don’t gamble.  Not that I hate gambling, or that I don’t understand the “thrill” that comes with it.  I just don’t gamble.

When I was in my early 20’s I went on a family vacation in Puerto Rico, and our hotel had a casino.  I had 5 quarters in my pocket when I sat next to a slot machine.

4 quarters went away in a blink of an eye.  The fifth gave me back 6 quarters, and as I was about to kiss the last one goodbye and move on, I won $86.

I took the money and ran off to rent a jet ski. That was it. I never put a single coin in a slot machine since.

I recalled this since 2014 starts off for me with an unusual sequence of travel destinations:  I just got back from Macau China two weeks ago from our APAC sales kickoff event, and I’m heading next to Las Vegas for the Microsoft annual Lync Conference.  The two biggest gambling destinations in the world, 1 month apart, for someone who doesn’t gamble. Go figure.

I don't gamble

2014 is starting off on a very positive note for our Lync program.  We have introduced a new high capacity session border controller (SBC) which has sufficient capacity to cover the data centers and headquarters of 99.9% of the world’s enterprises.  We focused significant development efforts on functionality, security and interoperability in the last 3 years, and in 2013 we were able to quickly scale up the capacity of our SBC.  I think that the timing is pretty good because we are seeing enterprises scaling up their Lync deployments, and as they start retiring legacy PBX and ISDN/T1 trunks, they are moving to SIP Trunking.  This is exactly where we fit in with our SBC, as part of our very successful One Voice for Lync offering which includes gateways, SBC, SBA, IP Phones and applications for Lync.

Our release got a lot of positive industry reviews such as the article Thinking Big with AudioCodes by Blear Pleasant on UC Strategies.

“That’s why AudioCodes is “thinking big” and introduced the Mediant 9000 Session Border Controller, which supports up to 16,000 concurrent sessions and extends the capacity of AudioCodes Mediant SBC family.  As part of AudioCodes’ One Voice for Lync product portfolio, the larger capacity SBCs enable enterprise customers to consolidate the network infrastructure for Microsoft Lync, simplifying training, deployment and support. AudioCodes and Microsoft have been working together for years, and AudioCodes realized that it was important to expand its SBC capacity in order to better support large Lync deployments. This is especially important as the momentum for Microsoft Lync continues to grow, with nearly 60% of enterprises with over 500 seats surveyed by Infotrack deploying or planning to deploy Lync.”

It was very clear to us that once we complete the networking products portfolio, the next step would be to offer a uniform management suite for it, and that we did!  We just announced our One Voice Operations Center which is a holistic suite of life-cycle management applications for large scale cloud or premise-based unified communications deployments.  With that, we are very well positioned to serve the largest of the Fortune 500 enterprises as they roll out Lync globally.

Just before the Lync conference starts, we will be hosting a closed user group event of top notch Fortune enterprise customers, for a round-table discussion about Lync global roll out best practices. Later in the week we are holding a “Vegas Style” party for our partners and customers. If you are coming to the event please make sure to stop by the Audiocodes booth #625.

All in all I expect we will have a great week in Vegas.

It makes me feel that if you plan properly, you don’t have to gamble…

Going native with WebRTC

Going Native with WebRTC

Going native with WebRTCIf you are reading this blog there is a good chances you heard about WebRTC and are well aware of the various products and services around it. Centering on enterprise communication and how WebRTC is being realized in this segment, the market is pretty much focused on one solution – a GW.

Now don’t get me wrong, WebRTC GWs are very important, you can’t really do without them if you want to overcome the slow deployment cycles and stay current with technology advancements. The point is that a GW is not enough. Let’s delve more into that.

The Typically Proposed “WebRTC for Enterprise” Architecture

If you look at some of the architectures used today for bringing WebRTC into enterprise networks they typically comprise a WebRTC GW and a media server that transcodes Opus to some other common codec, say G.729. Some options will also include RESTful APIs for configuration and creation of services on top. On the Audio side, there are cases where G.711 is used end-to-end but this option is not a preferred one from quality perspective when going over the open internet even though there are ways to add resiliency and improve quality even if G.711 is used.

A typical architecture of WebRTC GW Deployment

A typical architecture of WebRTC GW Deployment

 

The architecture described above is great, it will do the job. Question is, at what price.

Basically this architecture is kind of an “easy” way to bridge WebRTC into an enterprise network. You put a big box that will brute-force everything to what you have running on your network today. If that big box doesn’t provide the required capacity, just add another one.

There is another option

The most “expensive” component in GWing WebRTC into an enterprise network is the transcoding part. The way to work around this is by adding native support for Opus to the end devices. Doing so will yield quality improvement, cost reduction and preserve privacy. You can find a detailed technical overview why going native with WebRTC media on the end devices is important in an earlier blog post I published.

Reality is that Opus transcoding is extremely computing intensive so architecting this task on the server side will take a significant capacity toll on your system.

The flip side of this is that putting Opus on the IP Phone is complex. Assuming you are going for a SW upgrade and not a HW change, it requires flexibility in the phone architecture and hard work to get Opus running on it.

The subject of why adding Opus to existing IP Phones is complex interested me for a long time so I had a chat with our experts. Eli Shoval who is running our DSP Group and Oren Klimker, a team leader in this group.

The challenges in running Opus on an IP Phone can be summarized to be:

  • Processing power – Since not all IP Phones were born equal there needs to be optimization work and actual rewriting of some codec parts to make it run best on the IP Phone processor
  • Memory – This includes both footprint and run-time memory requirements. Opus is a feature rich codes that serves a wide variety of implementation scenarios; additionally, since sampling rate of Opus is higher than traditional VoIP codes memory required for an audio channel is increased

This in turn yields 2 main tasks required to overcome the MIPS and memory challenges:

  • Optimization – This work includes optimized implementation of some components of the Opus codec for both performance on the specific phone’s SoC (System on Chip) and memory consumption
  • Selective implementation – Part of the rewrite work needs to include removal of certain functions not required on an IP Phone

But there is Opus 1.1, doesn’t that solve the issue?

The short answer to this is NO.

In details, there are 2 reasons why Opus 1.1 doesn’t remove the need for native support for Opus on the end devices but rather make it even more essential.

The first reason is simple. Since transcoding will always add delay, reduce quality and impose cost on the server implementation; whenever possible, better to avoid getting into transcoding.

The second reason lies in the details of Opus 1.1 improvements. There is a pretty long list of changes, some such as surround encoding improvements don’t really touch the IP Phone requirements that much. What I want to take a closer look at is the speed improvements. As it looks, the team that built Opus 1.1 focused on improving the codec speed when running on ARM processors with NEON (do I hear mobile?), they reached up to 40% improvement. On the other hand, for x86 architectures there is no real improvement and in some cases things even got a bit worse. This can be seen in the diagrams below.

 

 

Opus 1.1 performance on ARM Cortex-A9 and i7-3520M

Opus 1.1 performance on ARM Cortex-A9 and i7-3520M

Source: xiph.org

 

This means that Opus 1.1 doesn’t bring good news to transcoding servers but it does improve the performance on some of the end devices.

Conclusion

As explained in this post and on earlier ones the preferred architecture for deploying WebRTC on any network and specifically on enterprise networks is one with end-to-end media without transcoding. The target should be to minimize the cases of transcoding to those where it is a must. Such cases as where traffic is going through a GW to PSTN or over SIP Trunks. In other cases, going native with WebRTC on the end devices is a preferred architecture.