[cisco-voip] SIP phone jitter, how do I find the culprit?

[Roger Wiklund]

On Sun, Feb 26, 2012 at 7:37 PM, Jason Dance <jason.dance at greenwich.com> wrote:
> Hello all!
>
>
>
> I am trying to work through a rather puzzling SIP issue on my CUCM 8.6
> system at the moment.  We have 10 non cisco SIP phones connected to our Call
> Manager, and we are experiencing a bit of jitter on certain inbound/outbound
> external calls (there doesn't sem to be a clear pattern though) and the
> audio on one side will sound robotic (we call it autotuning).
>
>
>
> We use 2 x Cisco 2811 routers, one hosting a SIP trunk to our Telco (runs
> CUBE, and has DSPs for codec translation), and the other is for a ISDN PRI
> trunk (also have enough DSPs to cover the channels).  Calls that hit the PRI
> trunk seem to do ok, so I think this is narrowed to a SIP phone => CUCM =>
> SIP trunk issue.  We use G.722/711 within the region/device pool assigned to
> the phones and CUCM, and we also use G.722/711 between the phones/CUCM and
> the region/device pool the CUBE is assigned to.
>
>
>
> For our switching infrastructure, we use 3750s for access layer with fiber
> uplinks to our 6509 distribution/core switch.  The 2811s are connected to
> the 6509.  Both sets of switches have QOS enabled, but I profess that I do
> not understand it at all well enough to mentally picture how it would affect
> traffic flows on this issue.
>
>
>
> With the above in mind, I'd appreciate any suggestions on:
>
>
>
> 1.) Some good methods I could use to track down where the jitter delay is
> being introduced.
>
> 2.) What path could I expect the SIP traffic to take? (I think the SIP legs
> go like: SIP phone <=> CUCM <=> CUBE <=> SIP provider, but I am not sure).
>
>
As SIP is only the signaling it's not super important what path it
takes, but it I would say yes to question 2.
RTP is what's important and I assume you use RTP flow-through in the
CUBE so your audio path should be:

Phone-----------------CUBE-----------------------ITSP

I would start by checking the routing/QoS from the phone to the CUBE.
That's most likely LAN so prob. no issues there.
Next step is to check CUBE----------------ITSP and I assume this is
over some sort of WAN, check routing/QoS there and ensure EF has the
highest prio with LLQ etc.

Look in your switches/routes for any drops in/problems in the EF queue
and see if you can find something strange.

/Roger