What Affects Cloud PBX VoIP Quality?
Migrating to and managing performance of a cloud PBX like the Avaya Cloud Office requires VoIP monitoring and VoIP quality test tools to ensure cloud business VoIP services deliver high quality, reliable VoIP calls to any location you do business. Cloud PBX performance is more difficult to optimize given that cloud PBX platform hosts may be located far enough from users to impact VoIP call quality (MOS score) and connectivity (CCR, CDR). An effective Cloud VoIP monitoring solution provides visibility into latency, loss and reachability from work from home and onsite users to cloud PBX platforms so you can quickly optimize network performance and cloud VoIP user experience.
This video shows how network path and performance monitoring can identify cloud PBX issues by region and user, and insight to optimize connectivity and VoIP call quality, using the Avaya Cloud Office as an example. This VoIP monitoring approach can help resolve issues with Avaya Cloud Office Login, call setup, retention and audio clarity. It can also be used to ensure a seamless migration to cloud PBX platforms from onsite IP PBX systems.
Try out Kadiska to ensure a seamless cloud PBX migration to any cloud PBX platform, including Avaya Cloud Office. Optimize cloud VoIP performance and caller user experience with in-depth network tracing that’s simple to deploy and use.
Video Transcript
Today we’re going to talk about. Migrating your PBX to a cloud PBX and seeing what kind of performance impact they may have for you.
So we’ll take a few quick look at the kind of things that are going to impact that kind of migration to a SaaS-based cloud PBX. And we’re also going to take a look at the performance drivers and how the network has to support those. So just a quick overview of that, I’m going to go back and give you guys a crash course in the MOS score of mean opinion score for IP.
I know you guys probably already know this already but it’s just worth revisiting before we go and look at some live data live in the internet. So what defines a good. Call on voice, super IP. It’s really the Mosco. Mosco is a factor. That’s perceptive. It’s qualitative. Basically you want to have a MOS above four to have a good quality call, and as it starts to drop, then you start to have dropouts in the conversation and start getting garbled speech or delay.
So it’s a good measure of whether or not your phone calls are going to sound good on IP. And you can see here, two of the key, major influences of that first one way latency. The delay between you and the other person you’re talking to, no matter what you’re going through in between you and that other person, if it’s gone through the PBX, of course, but other network segments, VPNs firewall, SD WAN, whatever’s in between you and the person you’re talking to the latency is really important.
So you can see around 75 milliseconds in one way, delay, you’re starting to get a drop that’s important, and you can start having some issues, understanding the person depending on the Kodak that you’re using for that, of course also packet. Very important. It’s almost intolerant to packet loss when you’re using voiceover IP for two reasons.
One is that dropping things out on a UDP transmission of packets means you’re going to lose chunks and segments of speech. And the other one is that you might just lose the call completely. So anywhere between one and 5%, you’re going to see calls dropping. So you don’t want to see that kind of percentage of packet loss in your stream or your conversation.
So that’s really the basics of the MOS score, and what’s interesting about packet loss and latency is that these things actually happen at the same time. So if you have a little bit of latency and a little bit of packet loss, you could get a perfect storm together and your call and MOS score are going to drop accordingly.
So we want take a look at those two as well. What’s the best practice? What are you trying to aim for when you’re delivering good voice for IP services? Latency, as we saw target around 50 milliseconds is where people don’t perceive any issues with a call. When you get to around 150 milliseconds in round trip you’re starting to really hear people talking over each other, maybe some echo packet loss. We talked about that, 1.5% is a point where you’re starting to see call drops and call quality issues.
And also there’s jitter or delay variation, which is a very similar latency, but it’s the variation between the receipt of packets, also a factor, but in voiceover, it there’s jitter buffers and echo counselors and different technologies that make that less important today than packet loss.
So these are the factors to think about when you’re migrating your PBX from local on premise to a cloud location. You have to make sure that the calls still retain those kind of quality metrics.
This is what you probably have now, if you’re migrating to a new cloud cloud voice for IP platform, you have your PBX here your public branch exchange running in a data center or in your headquarters is somewhere where people are going to be kicked. Connecting to it say from a retail location or from a work from home employee they’re connecting into this private network.
So if this call is not going out to somebody outside your company, it’s all internal to you. This is what it might look like. If you’re calling out to somebody in a different city or in another company or an individual, the PBX would then shoot the call out into the public branch exchange.
This is fairly straightforward. If you wanted to keep your latency and your packet loss low in this kind of simple environment, but as you move to the cloud, this PBX disappears and is being hosted up here somewhere out in outer space. Maybe not really, but actually the cloud, and it isn’t always just one location.
What you’ll see with a cloud PBX is that often they’re hosted in a variety of locations to be closer to the users, or to be regionally low latency . But when you’re connecting into it from work from home, it might be going through something like a secure edge device like a CASB security appliance or some other secure cloud gateway that might direct you to a particular cloud PBX. Also your DNS resolution in the different locations you’re at will be a factor in determining which of these cloud locations you’re going to end up talking to. And of course, the conversation that you’re creating has to go through these PBXs.
So if there are people in different locations, different countries, they’re likely going to be going through multiple of these cloud instances, which can introduce latency overall.
This is just a quick view of what it looks like when you’re moving to a cloud PBX. Now I want to show you specifically, if we take some examples, what it would actually look like in terms of achieving latency to those different locations, this is what you would do before you migrate to a cloud PBX.
So you want to make sure that all the locations you have in the world where you’ll be accessing from company sites, remote employees. Branch offices, manufacturing locations, that they’re all able to really reach these cloud PBX as well. But also to get to people that you want to talk to. So if you have a lot of your customers or in India, for example, you better make sure that you have a good latency to them as well.
So it’s important to be able to look through all this. So what we’re seeing here that Kadiska network tracing application that can tell us what the performance is to reaching any specific website or SaaS application from all these different locations around the world. And for our case here, what we’re going to do is we’re going to look for a specific target and that target is going to be the cloud platform.
You can see for our particular company, we have about 10 locations that we’re really interested in seeing how well we can access that platform. And now if you look carefully over here in north America, you can see that, for example, not a really good start for the guys in San Jose.
They’re 110 milliseconds away from the, a via cloud server. That’s bad, right? Because we’re already past the 75 milliseconds. You would need to have a successful call. And the fact that loss is already above 1.5%. So just starting here, we know that this probably isn’t going to be a very productive conversation.
Other areas in the States doing much better. If we look across the globe, it looks like actually strangely San Jose might be one of the worst places, unfortunately for us at Kadiska we have offices in Paris and the U.S. So the performance in France is also going to matter and depends on who’s talking to who, but you can have a pretty bad day if these things don’t work out too good.
So why don’t we look and see what’s happening here in San Jose. I’m interested in having a call with some people in Helsinki, and let’s say Toronto. So let’s take a look and see how those three can reach the Avaya cloud platform. So I’m just going to take Toronto, Helsinki, san Jose. And then I’m going to do a path performance trace.
And we’re going to take a look over how it is that we can reach that platform. So you can see here immediately on the loss over time side, there are some pretty bad packet loss events happening here. So we’re looking at 33% when you’re from San Jose, trying to reach the, Avaya cloud platform, you can also see from the round trip that if you’re in Toronto or Helsinki is almost no latency at all, it’s really working super well. But for some reason, San Jose it’s flipping between 75 milliseconds and 150. And what we’re seeing with this step increase in latency is really a change in that path. So the network path is changing.
And that’s why there’s a resulting increase in latency. So if we just took a quick look before we look at the what’s going on with that particular site in San Jose, you can see how each of these offices is connecting directly to the Avaya cloud platform. So from Toronto, it’s collecting to a platform over here and this one’s actually in AWS Canada.
So it makes sense. You’re in Canada, you’re connecting to a cloud platform here, the via CloudOffce here in Toronto. If you’re in Helsinki, you’re connecting to one that’s basically in, in Finland as well. So this is good news. You’re you’re oh no, it’s not good news. You’re going from you’re going across from Helsinki into the UK, and then you’re actually going across the ocean to Amazon.
AWS where they’re hosting the CloudOffice at Avaya. Unfortunately that’s located in the east coast, U.S. at the Ashburn data center. So that’s a long way to go for a call . So is a lot of network route that they’re going through or hopping into the network.
If you’re in our San Jose type office, you’d be going through Telia in the us. And then over here, you’re ending up at AWS hosting in France. Not good. So if you want to have a phone call and there’s actually a server in Eastern U.S., you’re actually going to France for that server that might explain where the latency came from.
Let’s take a look a little bit more because you can see, depending on the time of day, San Jose is flipping between the CloudOffice via platform in France and the U.S. We can take a look at that and see what impact that has on loss and latencies. So if we go up here, let’s just highlight delay across these different platforms.
And what you’ll see here is that there’s certain links in San Jose that are really causing significant latencies. So in the backbone here between the us on Telia, New York state, and then goes overseas to the UK, you’re seeing like, 140 milliseconds basically in here. And when the route stays more domestic, you can see there’s very little latency here, but there still is a problem between the U.S. And San Jose and the east coast.
So there’s some sort of traffic loop going on here with Telia. And you’d want to talk to them about that, if that was your only provider to that region, or maybe you’d want to choose to use a different internet or service provider to make sure you didn’t have that kind of delay going to CloudOffice.
We can also look at the loss to see if there’s any significant loss in these links. And you can see here that on the route going to the, if they’re connecting into their French. AWS site where they’re hosting cloud the CloudOffice, basically there’s a 22% packet loss happening here in the AWS cloud network, which will definitely be dropping all your calls.
So hopefully you’re not talking to somebody really important at that moment in time. And you can see how this changes around. So if I’m at in the low latency route, that’s going across to America. Very small packet loss. We’re hitting the platform in the east coast. That’s working well, but you see when there’s a route change on the internet and you’re forced over to France for some reason Telia has decided to do that because they have a better route or it’s lower cost to them or something like the cloud is asking them to load balance to another location.
That’s when the the loss is going to show up. And every time you go through this particular network path you’re going to have a digital experience that really falls well below your expectations. So if you’re troubleshooting this, or if you’re thinking of migrating to the Avaya cloud platform or any other cloud, IP PB X you’re going to want to trace your network performance to all these locations beforehand.
You’re going to make sure that the routes are stable and you have good peering partners and that the latency and loss to each of those locations is going to give you a really good MOS and a really good experience calling people. And you can do this all around the world.
We can set this up for you in less than a minute and you can easily do a quick assessment to make sure that your migration is going to be successful. So that’s what I wanted to show you today. A lot of great tools on Kadiska.com that you can learn about. And if you have any issues migrating to IP PBX or any SaaS application, just let us know. We’d be happy to help you out. Thanks for joining me today.
