tency queuing is the preferred QoS method for VoIP. When using this method, you create a single high-priority queue for data streams that cannot suffer dropped packets (voice, video, etc.), and the remaining data is queued according to a hierarchy of priorities. The priority queue may be assigned a percentage of the available bandwidth (15 per- cent, for example), or a finite amount of bandwidth (300 Kbps, for example). The priority queue should not consume more than three-quarters of the available band- width. In fact, the Cisco IOS prevents you from allocating more than 75 percent to the priority queue, though this value can be altered with the max-reserved-bandwidth interface command: Config-i - if# max-reserved-bandwidth 80 Determining Requirements WAN links should never be built with more than 75 percent planned utilization. 25 percent should always be left for overhead, routing pro- tocols, administration, etc. Because of the way the scheduler works, if you assign an unusually large value to the priority queue, none of the other queues will ever get serviced. This will result in apparent out- ages because only the priority queue's traffic will get through. We're going to assign voice RTP to the strict priority queue. For our purposes, let's say we'll need to allocate space for four G.729a codec VoIP calls (50 pps) at any given time. Some quick research shows that each call should take no more than 37 Kbps. Four calls at 37 Kbps equals 148 Kbps, which is the amount we'll assign to the priority queue: Voice RTP-priority queue-148 Kbps Call control requires very minimal bandwidth. Some Cisco documentation states that 150 bps (plus overhead) per phone should be guaranteed for call control. For four calls, that's only 600 bps. Other documentation states that 2-5 percent of over- all link bandwidth should be allocated for call control. For a T1, that's about 30-77 Kbps. Let's take the middle ground, and say we need 30 Kbps for call control: Voice control-30 Kbps We're only prioritizing telnet and SSH for emergenc