Posts

Skype for Business-To Cloud or Not to Cloud

Skype for Business: To Cloud or Not to Cloud?

Assessing the state-of-the-market following Microsoft’s announcements on enterprise voice in the cloud for Skype for Business

Skype for Business-To Cloud or Not to Cloud

Recent Microsoft announcements surrounding enterprise voice for Skype for Business in the cloud caused significant waves in the market.  Cloud PBX and PSTN calling will have a dramatic impact on the ecosystem. Yet, real parity between the on-premises Skype for Business Server and the online offering will still take a few years and many companies have concerns about making an immediate full transition to the cloud. These include:

  • Availability and regulatory issues requiring local PSTN connectivity
  • The current Online enterprise voice feature set is limited
  • Quality of Service over the open Internet can be problematic
  • Customers may not be in a rush to forgo existing contracts and working network devices
  • Customers may prefer a gradual migration of users to the cloud

Microsoft understood this and implemented a strategy to offer a solution for this market reality. At the July 2015 WPC event, Microsoft provided more details regarding deployment options. By offering a hybrid solution, where cloud-based PBX services are complemented by an enterprise’s on-premises based PSTN connectivity, Microsoft took their customers’ concerns into account. Their approach includes four deployment options, the middle two being hybrid versions:

  • Skype for Business Server On-premises: Users are registered to the local Skype for Business server; call management and PSTN connectivity are based on-premises. The Exchange Server is on- premises and there is no Office 365 connection.
  • Skype for Business Hybrid: Some users are registered to the Skype for Business Server (this could be in an appliance or in a private cloud) and some users are registered to Skype for Business Online. User identity is synchronized with Office 365 and voice mail is in Exchange Online.
  • Cloud PBX with on-premises PSTN: Users are registered to Skype for Business Online where the call management is handled by the Cloud PBX, but PSTN connectivity (also known as “bring your own carrier”) is handled on-premises through a local gateway or appliance.
  • Cloud PBX with PSTN Calling: Users are registered to Skype for Business Online and are on a Microsoft provided PSTN calling service, all managed by the Microsoft cloud.

Given that reality, a wise deployment of Skype for Business will mix on-premises functionality for corporate and call center users, allowing integration with legacy systems with initial deployment of cloud services. This will lay the foundation for a smooth transition to the full cloud solution down the line. The best way to protect the enterprise’s current investments, ensure a full enterprise voice feature set, guarantee that all company branches around the world are serviced and comply with regulations, is with a hybrid solution which offers the best of both worlds and allows the benefits of Unified Communications today with a secure and smooth migration to voice in the cloud when fully available.

Want to learn more about these 4 options and which one best fits your needs download this white paper – A practical guide for embracing the communications future.

Managing Voice Quality

3 Things Required for Managing Cross Network Voice Quality

So you’ve built your VoLTE network for high quality. You are providing high bandwidth to your customers so browsing and watching video is great. You also managed to get delay, jitter and packet loss down so voice calls are using WB-AMR giving your customers top quality.

Managing Voice QualityBut even though VoLTE is set to succeed, it will not happen overnight and it can’t be an island, there are other networks it needs to connect with. You need to allow for calls to GSM, PSTN and wireline VoIP.

To allow for this, you engineered your network in a way that if a call needs to exit the VoLTE network to any of the other networks you simply transcoded it to G.711. With that, it connects “without any issue” to any network out there.

So you connected your VoLTE network to other networks but that’s exactly when problems started to come up. Users started calling your contact center complaining about voice quality issues, they felt as if a mouse has cut the wire. Analyzing the complaints showed that there are problems not only when calling between the different types of networks but even when calling between VoLTE networks of different service providers.

Different type of networks perform differently

VoLTE

Think of a VoLTE network. It prioritizes voice over other data types. It will not retransmit voice packets even if there is packet loss (different from its handling of data) and it dynamically tunes rate, stuffing multiple voice samples into a single packet and add redundancy when needed.

In a VoLTE to VoLTE case, this results in great quality but when the destination is on a different network, that network handles things differently, resulting in quality issues.

GSM

On the GSM network, data will be retransmitted in case of packet loss, VoIP traffic included. This results in increased delay. Moreover, the 3G network works in burst mode sending a large amount of data to the core of the network in bursts, resulting in delay and jitter.

In case of voice TDM calls, NB-AMR is used which is, of course, different from what is used on the other networks.

Wireline VoIP

In the enterprise and consumer environments, VoIP provided by service providers typically uses G.729. The network itself is typically designed for wireline access but in reality many access it over WiFi. Needless to say that network behaviour is different in each case.

PSTN

Well, I guess there is no need to say too much about this subject. It is robust and voice quality is constant but at PSTN quality.

The brain and the tools that solve the problem

We have seen that different networks have different characteristics. That’s no news I guess. The conclusion though, is. Because this simple fact means that it is not efficient to decide on call setup properties and mid-call changes without knowing exactly the characteristics of the caller and callee networks.

Solving the quality issues when calling between networks requires three things:

  • Knowledge of all networks’ characteristics
  • Real-time monitoring information
  • Voice enhancement tools that will be managed dynamically based on actual call and network information

The entity that answers these requirements would be an SBC or a transcoding GW that resides in the core of the network. It would manipulate voice using various voice enhancement tools, decide on the best codec and rate for a call between the networks and use monitoring information for its decisions

On October 8th, I’ll be speaking on this topic at the LTE Voice Summit in London. If you happen to be there, drop by and say hello.

I will also be posting more information about voice call quality enhancement tools as well as a link to my presentation on SlideShare so stay tuned and be sure to follow: @AudioCodes and @AmirZmora

Here is a sneak peek to one of my presentation slides.

Voice Quality in Wireless Networks

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