SIP phone jitter, how do I find the culprit?

[Jason Dance]

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).

Thanks in advance,

Jason

[Rejohn Cuares]

To start with determine the ff.

- Any IP phone has diagnostics tools built-in. For example, in Cisco IP phones you can use the status information.

http://www.cisco.com/en/US/products/hw/phones/ps379/products_tech_note09186a00800945bd.shtml

- the round trip time from your CPE (Cisco 2811 Voice Gateway or hook up a PC assign it on Voice VLAN) to your SIP provider.

- Probably VoIP Dial-Peers have wrong settings. For example, VAD is turned on.

With regards to the traffic path, you are correct on your assumption.

[Jason Dance]

I just wanted to update this thread with what I discovered.

After running a bunch of traces, I found that the traffic from the sip phones were not being tagged with any qos values, yet my SCCP phones did have qos tags. After reviewing the configuration on the access layer switches where the phones were connected to, I saw that COS values were being applied only to the Cisco phones through the trust Cisco phone config on the ports (the sip phones are from a different vendor). After manually setting the cos to 5 on switchports that the sip phones are connected to, this seems to have resolved some of the issues we were experiencing. Need to test some more, but so far it looks like this was the problem.