Posts

Cards

We Lay Our Cards On The Table

Cards

AudioCodes SBC under the Miercom microscope

Quite often companies prefer to keep their cards close to their chest, no need to open up the product for others to find its soft points. We decided to take a different approach and let an independent 3rd party company put our products under attack, pushing their performance, resiliency and security to their boundaries. We are now putting our cards on the table giving everyone access to the results of these tests. The full Miercom report can be found here.

For this purpose we asked Miercom to run our SBCs through their brutal tests and report their results.

Miercom is a US-based network consultancy company, specializing in networking and communications-related product testing and analysis.

The products to be tested were the Mediant 4000B, Mediant 9000 and Mediant VE (Virtual Edition) Session Border Controllers. End result is a certification we received from Miercom for our SBCs’ performance, scalability and resiliency while under attack and overload conditions. The tests also verified the SBCs’ WebRTC Gateway functionality and monitoring capabilities with AudioCodes Session Experience Manager (SEM).

The AudioCodes Mediant SBCs

AudioCodes’ Mediant family of Session Border Controllers (SBC) is a line of versatile IP communications platforms that connect VoIP and TDM networks. SBCs are deployed at the border between the enterprise and the service provider. In the enterprise environment, they form an effective demarcation point between the business’s VoIP network and the service provider’s SIP Trunk, performing SIP protocol mediation and media handling (interoperability) and securing the enterprise VoIP network. In the service provider core, SBCs provide security and protocol normalization. Given this role, the performance, reliability and security of the SBC is imperative for successful operation of enterprise and service provider voice networks.

Miercom findings

“AudioCodes’ SBCs exhibit rich interoperability along with impressive performance and resiliency.”

AudioCodes Mediant SBCs offer advanced security capabilities that enable security detection, protection and analysis. They have a built-in application level IDS (Intrusion Detection System) feature that detects and suppresses malicious attacks directed at the SBC. Reactions can include blacklisting the assaulting IP addresses for a user-defined period of time and/or sending alerts (SNMP traps) with full details of the suspected malicious activity.

“The Mediant SBCs have proved fully resilient against Distributed Denial of Service (DDoS) attacks on both signaling and RTP/media ports, maintaining excellent MOS ratings and with no dropped calls or system degradation.”

AudioCodes SBC VNF

Ideally, all of the functionalities that are available within an appliance-based SBC should also be available within an NFV (Network Function Virtualization) version. While this may seem straightforward, some vendors struggle to deliver due to legacy product architectures which rely on hardware-specific feature implementations. This leads to challenges in assuring adequate performance and quality of service without purpose-built hardware.

AudioCodes Mediant VE can run as a Virtualized Network Function (VNF) in an NFV environment. It is one of the first SBC VNFs proven by Miercom to deliver effective protection against DDoS attacks, sustaining high performance while under heavy attack without sacrificing call quality.

AudioCodes NFV-based SBC provides full parity with traditional appliance-based SBC products, in large part because it has been available on leading industry x86 platforms since 2012. The virtual SBC design and software implementation allow it to protect against attacks without the need for purpose-built hardware.

To read the entire report, or for more details on how the tests were carried out, please refer to the full Miercom reports available on our website.

Garfield & Odie

The NSA is After My Grandmother Secret Lasagna Recipe

Commenter: Hi, can I ask a WebRTC related question?

WebRTC forum moderator: Of course, you are in the right place.Garfield & Odie

Commenter: My name is Garfield.

WebRTC forum moderator: Ahh OK, are you related to the cat?

Commenter: Seriously? When’s the last time a cat asked questions in the WebRTC forum?

WebRTC forum moderator: Good point.  How can I assist you today, Mr. ahh Garfield?

Commenter: I have a problem with a family secret which has been passed down from mouth to ear for centuries.

WebRTC forum moderator: And how is it related to the WebRTC forum?

Commenter: Well, I am quite old and I realized that this is a good time to pass the secret to the next generation. I have been told that WebRTC has the most secured media channel there is. So I thought this would be a good place to do it.

WebRTC forum moderator: If I may ask, how old are you?

Commenter: 15 years old.

WebRTC forum moderator: Excuse me? Ahh. Why don’t you pass your secret to your children?

Commenter: They’re on the other side of the ocean and I am afraid to do it on an international call.

WebRTC forum moderator: Why?

Commenter: Hey, I may be old but I’m not so naive to let the NSA learn about my grandmother’s secret lasagna recipe.

WebRTC forum moderator: I get your point. You heard right about WebRTC. Let me explain: The security mechanism in WebRTC is quite different than other calling systems. WebRTC mandates all media channels voice, video and data using DTLS protocol for security.

The browsers exchange a Datagram Transport Layer Security (DTLS) handshake on every media (voice, video and data) channel. Once these DTLS handshakes are completed, the media is encrypted and begins flowing between the browsers using Secure Real-time Protocol (SRTP).

Other calling systems are using SDES (used by SIP); in SDES the crypto is forwarded in the SDP via the signaling interface and can be used by the servers in the signaling path to decrypt the media.

SDES, which is used more in the SIP world, would help interface more easily to existing SIP-based infrastructure. Although there is consensus that DTLS will be mandatory for WebRTC to support, until two weeks ago, Google Chrome supported both SDES and DTLS. The most recent Chrome version no longer supports SDES. Mozilla Firefox never supported SDED.

In short, when using WebRTC end-to-end, eavesdropping is not an option; your grandmother’s lasagna secret recipe is safe.

Commenter: Many thanks, by the way, what happens if recording is a necessity such as in Contact Centers or where regulation requires it?

WebRTC forum moderator: In such cases, there are a few options. One option is using WebRTC client API for recording, however it’s a local solution.  An organization straight forward approach is to use a WebRTC GW with forking abilities, or a Session Border Controller which supports SIPREC for recording with WebRTC termination capabilities. The SBC then maintains two DTLS call legs toward each party of the call and in the middle; it forks the call to the recording server using a standard SIPREC protocol.

WebRTC Recording with SIP-Rec

Commenter: It’s strange that you are mentioning SBC’s in this context, since a few weeks ago I read in BlogGeek.me that SBCs are not required in the WebRTC world.

WebRTC forum moderator: That’s true when making a call between two browsers but there will be a need for a border element to be between the WebRTC world and the SIP world, WebRTC GW (SBC), to terminate WebSocket, DTLS, ICE and OPUS transcoding.

Commenter: That’s very intriguing! So do you think it is safe to send Pomodoro Siciliano over the WebRTC data channel too?

WebRTC forum moderator: I would recommend starting moderately with the basil.

Commenter: Meeow…..

WebRTC forum moderator: Oh my……..

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

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.