OCS and LiveMeeting with Overseas Users

Here at PointBridge we have a group that works overseas in Pune, India. And since we use LiveMeeting and OCS internally we thought it would make sense to use OCS to save on international calls to and from India. But note: we don’t have a dedicated WAN connection to Pune: it’s all over the Internet.

After about a month or so, I got a report that the calls weren’t going so well. The quality was hit or miss; when it was good it was good and when it was bad, it was unbearable. For the most part, members of the team here in Chicago felt that it was just more useful to use our 800-number conference bridge.

So I did some investigation using our OCS Qualtiy of Experience (QoE) server reports. These reports tell you great detail about each call, networks stats, MOS (mean opinion scores) of calls etc. The QoE server, in my opinion, is a must. The reports that it provides are so useful to an organization deploying VoIP. I highly, highly, recommend installing and using the QoE server if you are using OCS for voice. Anyway…. Here’s what I found.

Past Performance – calling with India

Dec-Jan (8 weeks) reports on the QoE server showed a total of about 40 calls between us and Pune, almost all of them using the livemeeting client. This was interesting news, because the LiveMeeting client uses a different protocol (Siren) versus the Communicator-to-Communicator protocol (RT Audio).

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

I don’t have network stats on all calls, but for those that I do, here is the one-way network latency:

In order for there to be no noticeable quality degradation, you need a one-way time of 150ms or less. It’s usually acceptable around 225ms one-way, but much beyond that and it causes trouble, even with OCS’s built-in mechanisms. So half of the calls are ok, half are not. This also bears out the "when it’s good, it’s good; when it’s bad it’s awful" feedback. Notice the jump between 220ms and 822ms. That’s huge – and there are no calls in between.

So is it OCS or the Network?

I’ve pinged a few well-connected servers and ISP routers in India and it looks like the one-way trip to India takes around 100-180ms. It’s not bad, but that’s just pinging. It’s also interesting to see that once your packet leaves the US (usally via New York) the delay goes up by almost 100ms instantly.

Anyway, the 100+ms of network delay is added to by digitization/processing on the OCS side, which can regularly account for an additional 30-40ms delay. So we are looking at around 130ms one-way in a best-case scenario. If any of the links between us and Pune (or the LAN in the Pune office) is congested, it will add more latency. This is corroborated by the network stats above. A few things to take away:

• The big problem: Pune is far away and, under ideal conditions, is close enough for us to have good enough network for voice calls
• The excellent MS whitepaper on QoE/QoS comes right out and says: "Delay is the one [network] impairment that Microsoft UC cannot reduce, and it is important to find and eliminate the weak points."
• Since we don’t have dedicated lines to Pune, we can’t relay control the network, like serialization delays, jitter etc.
• Going over the Internet means that packets take various routes over the ocean to get here. One day it might go through NYC, one day it might go through Japan, one day it might go through Australia. You never know.
• Internet routers, when busy, will dump packets. VoIP hates that.
• These calls are all using LiveMeeting, which uses a different audio protocol than Communicator-to-Communicator or Communicator-to-PSTN calls. It’s not as flexible as the Communicator-to-Communicator calls and doesn’t handle network degradation as well

Conclusion

I’ll continue to monitor calls but it’s probably not going to tell us anything we don’t already know: voice quality to India over the Internet will be intermittent. I believe that we’ll see better performance with communicator-to-communicator calls.

Domestically, I’ve never had any trouble whatsoever making trans-continental calls: from Chicago to California; Chicago to Florida; Florida to California. I haven’t had a single bad call. But the additional minimum 100ms of delay that calls to India really places a burden on voice quality. And while OCS can do quite a bit to smooth things out, 1000ms of delay is going to make your calls bad, no matter what.