[c-nsp] VoIP without QoS

[Dan]

We have a voip system we have been running in our department now for
about a year.  Only 12 phones, connected through various wireless links
with throughput of up to 40mbit.  Speed is definitely not an issue for
us, but we notice glitches with the quality on an ongoing basis.  We are
currently implementing qos and are wondering what is the best way?

Jared,

You mentioned you "cheat" by rate limiting other traffic.  What is the
recommended way to implement qos for voip and video?  We have 3550,3560
and 2960 switches.

Dan.

, Jared Mauch wrote:
> On Tue, May 22, 2007 at 01:48:48PM -0400, Lamar Owen wrote:
>   
>> On Tuesday 22 May 2007, Nassess, George wrote:
>>     
>>> I am in the process of extending our distributed VoIP call center to a
>>> partner company, and their networking staff are extremely adamant that
>>> they do not wish to implement QoS on their remote LAN, the DS3 link that
>>> the voice traffic will traverse, or the core LAN in our shared
>>> datacenter. 
>>>       
>> I too would like to see a good discussion of this, as I'm getting prepared to 
>> implement VoIP here, on an 8540MSR core with Catalyst 5500-series 
>> distribution-access switches (using RSM's and RSFC's in each 5500-series to 
>> provide dual layer 3 uplinks into the core, collapsing access and 
>> distribution); Cat 5500's and 8500's don't implement all the things VoIP is 
>> supposed to require, but I'd like to see both sides, too.
>>     
>
> 	I've typically "cheated" in doing voip QoS by rate-limiting TCP
> traffic in one direction.  This keeps the TCP traffic from taking the
> entire link and results in a basic reservation of traffic.
>
> 	here's an example: (you may need to modify this based on platform)
>
> interface Serial0/0
>  description T1 to somewhere
>  ip address 1.2.3.4 0.0.0.0
>  rate-limit input access-group 106 1280000 4470 8000 conform-action transmit exceed-action drop
> !
> access-list 106 permit tcp any any
> !
>
> 	The result is ~256k of reserved bw on a t1, enough for ~2x88k
> g711ulaw streams.
>
> 	simulating the tcp loss with the rate-limit causes tcp to think the
> link is smaller, yet leaving headroom for the udp bits :)
>
> 	works well for a home network, you may need to adjust depending on
> other streaming media applications that are udp based (perhaps they need to get
> matched in your access-list 106) and depending on what you do.
>
> 	As long as you don't have any true congestion and output drops
> on your interfaces (i assume you graph these?) you should be ok without the
> qos stuff.
> g711ulaw streams.
>
> 	simulating the tcp loss with the rate-limit causes tcp to think the
> link is smaller, yet leaving headroom for the udp bits :)
>
> 	works well for a home network, you may need to adjust depending on
> other streaming media applications that are udp based (perhaps they need to get
> matched in your access-list 106) and depending on what you do.
>
> 	As long as you don't have any true congestion and output drops
> on your interfaces (i assume you graph these?) you should be ok without the
> qos stuff.
>
> 	- jared
>
>