[cisco-voip] Strict Priority Queuing over T1 for Voice

Tue Oct 24 18:13:45 EDT 2006

One thing to add...

I am testing now by saturating the link and making an internal call to
another IP phone at another remote site that of course goes over the
same T1 (plus another T1) and I do not see any jitter or rxlost
problems.  I had noticed that I never saw any problem to our other
office so I wanted to test it now.  Max jitter is only 29 and no rxlost
in 12 minutes so far with the T1 saturated plus the stream has to go
over another T1 as well.

Could this be an issue with the 6608?  I remember coming across a bug
about the sample size changing from 10ms to 20ms using g729 on a 6608
resulting in poor quality.  That bug fit perfectly, but it was for ccm
3.0.10 I think.

Anyway, this is getting stranger by the minute...  ;) 

________________________________

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Keith Klevenski
Sent: Tuesday, October 24, 2006 4:43 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Strict Priority Queuing over T1 for Voice

Hi all,

I've been battling a problem that seemed to have surfaced recently as we
have added more users to the office.  We have an office of about 35
users now with a point to point T1 (HDLC) between this office and the
datacenter where the CallManager's (running 4.1.3) and PSTN gateway
(6608 blade) are.  Basically this:

PSTN

  |

6608/6509 (datacenter) (12.1(11b)E14 on msfc and 6.4(10) on sup)

   | trunk

7200 (datacenter) 12.3(6a)

  |

T1

  |

2811 (remote office)  12.3(11)T7

  | trunk

3750 (remote office)

  |

Phones

We have strict priority queuing configured on the T1 interfaces (and the
FastEthernet interfaces although I don't think this is necessary) with
DSCP EF traffic in the high queue and signaling (AF31/21/22/23 and CS3)
the medium queue and other traffic in the normal and low queues.  

The problem is when the T1 is saturated we start seeing high jitter (1-2
seconds) and rxlost packets on the phones and voice quality of course
suffers.  The thing is I see NO dropped packets on any interface from
the PSTN to the switch port the phone is connected to other than the
call statistics on the phone.  This confuses me greatly unless the phone
itself is dropping them... it would seem that if the phone determines
there are missing packets (rxlost) they would show up on some interface
somewhere but they do not.  Sniffer traces at the phone show the missing
packets.  Sniffer traces at the trunk at the remote office show missing
packets, but traces on the trunk in the datacenter (from the 7200 to
6509) show all packets accounted for.  Seems like the T1 is the issue.
There are 24 line code violations on the T1 in the last 24 hours, but no
slips.  The problem only seems to occur when there is high traffic on
the T1.  We also noticed no other traffic is marked EF and the RTP
stream is EF at the datacenter and at the office so that isn't being
remarked or anything.  But there are no input queue drops on the 2811
(which I wouldn't expect since the RTP stream should be CEF switched
anyway).  If the input interface cannot handle the amount of traffic and
the traffic is all CEF switched where would you see input drops?  There
are a handful of buffer failures, but nothing that would account for the
number of complaints I've been getting lately.

I've connected my phone directly to the 2811 and bypassed the 3750 with
the same results.

I also noticed that the rxsize fluctuates between 10ms and 20ms also.
Shouldn't that always be 20ms?  I thought that was odd.

I guess my main question is when using strict priority queuing shouldn't
the voice packets ALWAYS get sent first no matter what??  I want to
believe they are since there are NO drops in the high priority queue
outbound from the datacenter.  What is the best way to do QoS for voice
over a T1 when you only care about the voice?  Seems like strict
priority queuing is the best way to assure voice traffic is sent first.
We don't really care about starving out any other traffic.  If packets
are being dropped shouldn't I see them somewhere other than on the
phone?

Any input on this problem is welcome!

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20061024/f672ff92/attachment-0001.html 