Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

QOS for Voice & Video (MCM/Proxy)

Hello Chris and all

I'm currently in the design stages on a pretty cool

project. I have 7 remote sites and one central site.

These remote sites are all point-to-point links.

Essentially I have 7 T1's terminating at the hub site. (DS3 is not available)

The customer is currently utilizing H.320 legacy video equipment on three of his locations, as well as interfacing via 28 FX0's and 22 FXS's to the hub site PBX. The remote sites have various flavors of FX0's and FXS type connections to the remote site key systems.

I'm going with IP/H323 on the voice and video. Using 3600’s on all sites (too many FXO’s & FXS’s) I'm planning on using the 3530's for the legacy H320 conversion and the 3510 for the MCU and the MCM/proxy at each site for the QOS tagging and ip rtp priority queuing for the queuing.

My question is:

Wouldn't the video H323 also use this same priority queuing mechanism as the voice? (Since they’re both H323) Is this the best queuing mechanism to use?

Would LLQ be a better alternative? And will LLQ work with both

the voice and the video? What's the best QOS to use?

I want to make sure, I'm applying the best QOS solution that will work with both services. (voice & Video)

Thank You


New Member
New Member

Re: QOS for Voice & Video (MCM/Proxy)

Can someone please post an answer to his questions please, instead of links. Thanks, Dylan sends

New Member

Re: QOS for Voice & Video (MCM/Proxy)

The recommended solution is to use 2 separate LLQs for voice and video-confernecing traffic. Having voice and VC co-exist on the same LLQ can be disruptive as video packets have much higher variability in size than does voice-only and uses more variable bandwidth in the context of the call. Also recommended is using Prec 5 for voice and 4 for for the video conference traffic. RSVP would also be helpful to reserve b/w and determine path in a multi-hop environment. Hope this helps.