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

QoS in ip telephony

Hi,

I want to do Ip telephony and I see different doc about QoS.

I want implement QoS for Ip telephony in a router 1700 and I want to know if somebody can advice me to use Intserv or Diffserv with DSCP.

Thank you in advance

p. Martiny

3 REPLIES
Silver

Re: QoS in ip telephony

Depends on what you have in your network. If your voice is originating on the 1700 router then you can do diffserv by classifying the media under the dial peer as ip dscp media ef, and then matching the packets using a class map and then you can do whatever you like, for example LLQ.

If your voice does not originate on the 1700, then you have to find out what the RTP packets are being classified as and then use an access list to match those packets and then apply some sort of queing for the QoS.

Hope that answers your question

Community Member

Re: QoS in ip telephony

Thank you for your answer.

In fact i want to do ip telephony between two compagny

Netwark A ( Router 1700 ) ----- NET ------- ( Router 1700 ) Network B

And in this case, i want to know what kind of QoS I must use.

Thank you in advance

P. Martiny

Community Member

Re: QoS in ip telephony

Hi ,

The flavour of the year is LLQ ,your voice gets strict priority over everthing in THE "PRIORITY" que then you can setup other classes VOICE signalling etc etc use the bandwidth command to give these classes of traffic a share too during congestion periods.Voice will be serviced first always.

You can do IP rtp priority which uses udp ports 16382 --. 32784 and this has priority over everthing you could also use it with LLQ though not recomended.

IP rtp priority would have priority if you did.This has gone out of fashion : )

LLQ is better because you can be much more granular in your config your not restricted.

There are heaps of links on CCO ,you configure it using The modular quality of service command line interface dont let this confuse you though the config is basic thats what Cisco call it.

hers a little example from CCO

router(config)# class-map voice

router(config-cmap)# match access-group 102

router(config)# policy-map policy1

router(config-pmap)# class voice This is the class it matches access-list 102

router(config-pmap-c)# priority 50 This is the priority which will use 50k

router(config-pmap)# class bar

router(config-pmap-c)# bandwidth 20

router(config-pmap)# class class-default

router(config-pmap-c)# fair-queue

router(config)# interface atm1/0

router(config-subif)# pvc 0/102

router(config-subif-vc)# service-policy output policy1

router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000

router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000

Basically you create a policy with class and you can assign to any and all interfaces ITS modular : )

A link for you good luck

http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html#wp5329

### from link###

The Low Latency Queueing feature brings strict priority queueing to Class-Based Weighted Fair Queueing (CBWFQ). Strict priority queueing allows delay-sensitive data such as voice to be dequeued and sent first (before packets in other queues are dequeued), giving delay-sensitive data preferential treatment over other traffic.

Without Low Latency Queueing, CBWFQ provides weighted fair queueing based on defined classes with no strict priority queue available for real-time traffic. CBWFQ allows you to define traffic classes and then assign characteristics to that class. For example, you can designate the minimum bandwidth delivered to the class during congestion.

For CBWFQ, the weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it. Therefore, the bandwidth assigned to the packets of a class determines the order in which packets are sent. All packets are serviced fairly based on weight; no class of packets may be granted strict priority. This scheme poses problems for voice traffic that is largely intolerant of delay, especially variation in delay. For voice traffic, variations in delay introduce irregularities of transmission manifesting as jitter in the heard conversation.

The Low Latency Queueing feature provides strict priority queueing for CBWFQ, reducing jitter in voice conversations. Configured by the priority command, Low Latency Queueing enables use of a single, strict priority queue within CBWFQ at the class level, allowing you to direct traffic belonging to a class to the CBWFQ strict priority queue. To enqueue class traffic to the strict priority queue, you configure the priority command for the class after you specify the named class within a policy map. (Classes to which the priority command is applied are considered priority classes.) Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, strict priority queue.

One of the ways in which the strict priority queueing used within CBWFQ differs from its use outside CBWFQ is in the parameters it takes. Outside CBWFQ, by using the ip rtp priority command, you specify the range of UDP ports whose voice traffic flows are to be given priority service. Using the priority command, because you can configure the priority status for a class within CBWFQ, you are no longer limited to a UDP port number to stipulate priority flows. Instead, all of the valid match criteria used to specify traffic for a class now applies to priority traffic. These methods of specifying traffic for a class include matching on access lists, protocols, and input interfaces. Moreover, within an access list you can specify that traffic matches are allowed based on the IP Differentiated Services Code Point (DSCP) value that is set using the first six bits of the Type of Service (ToS) byte in the IP header.

Although it is possible to enqueue various types of real-time traffic to the strict priority queue, we strongly recommend that you direct only voice traffic to it. This recommendation is made because voice traffic is well-behaved, whereas other types of real-time traffic are not. Moreover, voice traffic requires that delay be nonvariable in order to avoid jitter. Real-time traffic such as video could introduce variation in delay, thereby thwarting the steadiness of delay required for successful voice traffic transmission.

Guaranteed Bandwidth

When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kilobits per second (kbps). You use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class.

In the event of congestion, when the bandwidth is exceeded policing is used to drop packets. Voice traffic enqueued to the priority queue is UDP-based and therefore not adaptive to the early packet drop characteristic of Weighted Random Early Detection (WRED). Because WRED is ineffective, you cannot use the WRED random-detect command with the priority command. In addition, because policing is used to drop packets and queue limit is not imposed, the queue-limit command cannot be used with the priority command.

When congestion occurs, traffic destined for the priority queue is metered to ensure that the bandwidth allocation configured for the class to which the traffic belongs is not exceeded.

Priority traffic metering has the following qualities:

It is much like Committed Access Rate's (CAR) rate limiting, except that priority traffic metering is only performed under congestion conditions. When the device is not congested, the priority class traffic is allowed to exceed its allocated bandwidth. When the device is congested, the priority class traffic above the allocated bandwidth is discarded.

It is performed on a per-packet basis, and tokens are replenished as packets are sent. If not enough tokens are available to send the packet, it is dropped.

It restrains priority traffic to its allocated bandwidth to ensure that nonpriority traffic, such as routing packets and other data, is not starved.

231
Views
0
Helpful
3
Replies
CreatePlease to create content