[c-nsp] VoIP without QoS

Jared Mauch jared at puck.nether.net
Tue May 22 14:29:04 EDT 2007


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

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


More information about the cisco-nsp mailing list