In order for a queuing mechanism like LLQ or IP RTP Priority to queue voice packets into a priority queue correctly, they must be able to identify the traffic as VoIP. With IP RTP Priority, packets are matched and priority queued according to the UDP port numbers used by RTP voice traffic, which fall into the range 16384 to 32767 (even port numbers only) in Cisco implementations. Odd UTP port numbers in this range are used for call control information, and are not prioritized – they are serviced by the WFQ method like all other traffic.
With LLQ, VoIP traffic is typically determined based on either port numbers (through the use of access lists), or through traffic classification mechanisms. If you recall from Chapter 4, IP headers includes a field that can be used to designate a service “type”, also known as Type of Service (ToS) or IP Precedence. Based on the value configured in this field, network equipment like routers can be configured to grant certain types of traffic (like VoIP) a higher priority based on the queuing methods in use. For example, on a network that supports voice traffic, all voice packets could be tagged with an IP Precedence value of 5. Because this setting is configured in the IP header, it will stay with a packet all the way from the source to the destination, helping to ensure end-to-end QoS, again assuming an appropriate queuing mechanism that considers this information is implemented on all intermediary routing equipment. LLQ would be the logical choice in such a scenario. On most networks, VoIP traffic has its IP Precedence value configured at the edge of the network, namely on an IP phone. In some cases, however, the phone might not have this ability, and IP Precedence settings might be added to the packet at the distribution layer according to configured policies.