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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Dial Peer IP Precedence Value

When I set the Ip precedence value on a dial peer is this used for all traffic from the dial peer ie call setup and voice (rtp) or just for the voice(rtp)?

Cisco Employee

Re: Dial Peer IP Precedence Value

It depends on which version of IOS you are running. Starting around 12.2(8)T, the following commands allowed you to specify the RTP and signaling traffic QOS marking under the voip dial-peers separately:

ip qos dscp xxx signaling

ip qos dscp xxx media

(where xxx is the dscp value)

Typically, DSCP marking should be EF for media (RTP) and CS3 for signaling (in past marking for signaling was AF31 for DSCP, however there has been a shift to CS3 for signaling recently).

To see what the marking is for a particular dial-peer, use the following command:

show dial-peer voice ###

(where ### is the number of the voip dial-peer you want to look at).

Check out the values for "ip media DSCP" and "ip signaling DSCP", these will be the marking for the respective traffic.

This is all dependent on the version of IOS and earlier versions of IOS may not provide the ability to adjust packet marking for both media and signaling and typically an IP precedence value set on a dial peer on early versions of IOS applied only to the media stream only.



New Member

Re: Dial Peer IP Precedence Value

Thanks for you reply:-

The software we are running is 12.2(16b)

The config on the router is:-

dial-peer voice 102 voip

destination-pattern 02T

session target ipv4:

ip precedence 5


Below is the output from voice peer 102

GHT_Crawley_2621XM#sh dial-peer voice 102


information type = voice,

tag = 102, destination-pattern = `02T',

answer-address = `', preference=0,

numbering Type = `unknown'

group = 102, Admin state is up, Operation state is up,

incoming called-number = `', connections/maximum = 0/unlimited,

DTMF Relay = disabled,

modem passthrough = system,

huntstop = disabled,

in bound application associated: DEFAULT

out bound application associated:

permission :both

incoming COR list:maximum capability

outgoing COR list:minimum requirement

type = voip, session-target = `ipv4:',

technology prefix:

settle-call = disabled

ip precedence = 5, UDP checksum = disabled,

session-protocol = cisco, session-transport = udp, req-qos = best-effort,

acc-qos = best-effort,

fax rate = voice, payload size = 20 bytes

fax protocol = system

fax-relay ecm enable

fax NSF = 0xAD0051 (default)

codec = g729r8, payload size = 20 bytes,

Expect factor = 0, Icpif = 20,

Playout Mode is set to adaptive,

Initial 60 ms, Max 200 ms

Playout-delay Minimum mode is set to default, value 40 ms

Max Redirects = 1, signaling-type = cas,

CLID Restrict = disabled

VAD = enabled, Poor QOV Trap = disabled,

voice class perm tag = `'

Connect Time = 1766764, Charged Units = 0,

Successful Calls = 58, Failed Calls = 2, Incomplete Calls = 2

Accepted Calls = 92, Refused Calls = 0,

Last Disconnect Cause is "10 ",

Last Disconnect Text is "normal call clearing.",

Last Setup Time = 215780472.

From what you have said I assume that only the RTP data has the Ip Precedence set to 5.

Many Thanks for your time and answer.

New Member

Re: Dial Peer IP Precedence Value

Jordy - Would you care to elaborate on that shift from AF31 to CS3? What would be the driver for peferring the CS value?

Cisco Employee

Re: Dial Peer IP Precedence Value

Without out going into a whole lot of detail, basically it comes down to this:

RFC 2597 defines the assured forwarding (AF) classes. There are four AF classes, AF1x through AF4x. Within each class, there are three drop probabilities. These drop policies are low, medium, and high. AF31 incidently falls in the low drop probablity group. From a QOS perspective, sending traffic such as voice signaling (which is critical to voice media) with a marking that might result in it being dropped (albiet the chances are low) is a bad idea. Instead by sending signaling at DSCP CS3, we've eliminated the whole drop probability associated with the Assured Forwarding DSCP marking. This isn't to say that these packets can't or won't be dropped, it's just not a built in mechanism.

Hope that helps.



CreatePlease login to create content