Networking considerations for CS “14”

I attended a great session from TechEd on Network Considerations given by Neil Deason. In it he discussed Audio, Video, and Application Sharing within CS14. When looking at audio traffic it’s important to review network conditions, acceptability quality of the call as well as optimal quality. Narrowband is typically used for traditional calling and it doesn’t span the human ear hearing spectrum but is good enough for the far end to understand our call and make error correction themselves.  

Understanding the capacity that’s needed for these different experiences can be difficult to ascertain as Voice Quality itself is broken up into the areas of Network, core performance (performance of server h/w and s/w), gateways, and devices. Our goals for the network optimization are to provide voice based on acceptable and optimal quality. I need to have less than 10ms of jitter with a max of less than 80ms of jitter.

Packet loss might seem like a lot but this is against the entire experience and should not be looked at in consecutive packets as this would indeed impair call quality.

How much bandwidth is required is determined by the following:

• Codec Choice.
• Network performance
• Voice activity and Video Content

Bandwidth Profiles

This chart gives us typical bandwidth and upper limits with and w/o Forward Error Correction (FEC). When planning you should work with typically numbers to start with.

These bandwidth profiles can be used with Call Admission Control (CAC) to provide group policies to be applied in logical sites (subnets). They can allow sessions to only go as big as the profile allows and setup rules for what to do when the users session exceeds that level such as reroute traffic or dropping the session. One cool thing that you can do is redirect the session to the Internet for overflow of traffic to avoid PSTN call charges and to support failover for things like video sessions.

This example used at technet describes a session where we are using a communicator to communicator call. We are using a RTAudio Wideband (no FEC) codec which as you saw above is about 35kbps. This is well within the CAC policy parameters above and the endpoints are intelligent and provide for a great wideband session. Now if we move the user outside the f/w to the Internet we will still use RT Audio WB(No FEC) if the network quality is good.

Now the Internet quality has degraded the session and we switch the call to RTAudioNB (+FEC) instead of RTaudioWB(+FEC) due to the CAC policy of 60kbps. .

The call continues and we now have error correction. Key to this discussion is that we will continue to check for call quality and adjust the codec as necessary. All in all very cool stuff. I would recommend sitting the entire session here if you can.