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

Troubleshooting High ICPIF values

We've been receiving traps for "Poor Quality of Voice" for sporadic calls from several of sites across our VoIP network. If I'm understanding what I'm reading, the trap is being sent when CvVoipCallHistoryIcpif is too high.

I'm trying to figure out what is causing the ICPIF value to get where it is at (59 or 66 depending on the codec). One-way transmission time is listed as one of the values used in the calculation. Is there a way to see what the one-way times are for a given call? I know that RoundTripDelay is listed in the call history, but wasn't sure if it affected the ICPIF value directly or if another measurement was used.

It was my initial thought that RoundTripDelay was the trigger, since I've seen times upwards of 32000ms, but in these cases, the value of CvVoipCallHistoryIcpif is sometimes 59/66 and other times zero.

Packet loss doesn't seem to be an issue either. Is there a specific value I can look at to see what "one-way tranmission time" is being used for ICPIF?




Re: Troubleshooting High ICPIF values

Here are some notes on how this value is actually calculated in IOS and how it can be used(compiled from several sources including news, docs, specs and the source code)

To calculate the overall Calculated Planning Impairment Factor we allocate a value of distortion to each network element and then allow the simple addition of these impairments.

Network elements that we calculate variable value for are

- codec

- packet loss percentage

- delay

Network elements that we do not measure and consider constant and negligible compared to

mentioned above are

- PCM type quantizing distortion

- non-optimum overall loudness rating OLR and/or high circuit noise

Talker echo is actually not measured also.

The function that calculates the icpif value works as follows

1. We have measure voice quality in the testing environment basing on waveform deviation

with PSQM at discrete packet loss levels. For given codec type we have

created a reference table of voice distortion values allocated to that discrete packet

loss levels.

2. To calculate value of distortion as a function of packet loss percentage we do linear

approximation on that table.

For G.729 the table is 0=>10, 1=>15, 2=>20,

3=>25, 4=>30, 5=>34, 6=>38, 7=>40, 8=>42, 9=>44. For G.711 the table

is: 0=>0, 1=>8, 2=>12, 3=>18,

4=>22, 5=>26, 6=>28, 7=>30, 8=>32, 9=>34.

Those values are based on measurements done using Cisco enhanced PSQM (ITU P.861). Only

for G.711 and G.729 tables are actually defined. If codec is not G.729, G.711 table is


3. We have defined based on G.113 a reference table of voice distortion values allocated

to discrete delay values.

4. Again to calculate value of distortion as a function of packet loss percentage we do

linear approximation on that table.

The table is 150=>0, 200=>3, 250=>10, 300=>15, 400=>25, 500=>30,

600=>35, 800=>40.

We ignore other factors as either negligible or as already reflected in delay or packet

loss (like delay variation either increase jitter buffer and thus contribute into

end-to-end delay or result in packet loss and are reflected by this factor). Echo is also

not taken into our calculations as already mentioned.

5. We then do simple addition of these impairments values to determine the overall

equipment impairments, Itot.

If Itot <=expectation factor, Icpif=0 and it's assumed best possible quality

If Itot > expectation factor, Icpif = Itot-expectation factor If Icpif <= configured

icpif threshold

- still good quality

Then you can use snmp traps.

If Icpif > configured icpif threshold, SNMP trap can be generated.

So, the calculated icpif must be greater than the configured icpif for the trap to be

generated. So set expectation factor low and icpif low to ensure a trap is

generated. Also from debug cch session (hidden command) and sh call hist voice you are

supposed to see what the system is calculating for your calls. Note, calls

must last more than 10 seconds or we won't attempt an icpif calculation.

There can be an other way.

The factors for poor QoV calculation are delay, loss(gap), echo and

codec type. 10 seconds sample duration is good for collecting the data for delay, echo and


For playout gap (unit milliseconds), we need to find few gaps to conclude the poor QoV.

You can set the expect factor to 0 and collect the 'delay', 'codec', 'gap', echo

information from call history if you detect poor QoV and no trap.

This url should help you:

Busy Signal after Last Digit Dialed on H323 Incoming Call (CM 3.0)

Troubleshooting One Way Voice Issues:

CreatePlease to create content