Jitter in cucm

Answered Question
Feb 16th, 2010
User Badges:

Hello,


Was looking at the CAR report in my cucm and i am seeing excessive packet loss,jitter and latency at the destination phone. while the users themselves dont seem to complain. Wondering if it has got to do with device at destination happens to be 7906.

Any input is appreciated.

Thank you..

Correct Answer by William Bell about 7 years 4 months ago

First, you have to keep in mind that CAR's CMR statistics should be taken as clues rather than as definitive proof of an issue.  I have seen jitter and packet loss be reported incorrectly by devices.  Sometimes this is due to a software defect so you can check the bug toolkit against your CUCM version and phone firmware.


In lieu of that, I would recommend the following:



1. See if you can localize the issue to the access network.   Check jitter/packet statistics for other phones that are on the same network as your suspect IP phone.  Prefereably on the same switch or even switch blade (if you use modular access switches).  If you see other phones reporting the same general experience then you should definitely dig deeper into the network.


2. See if you can localize the issue to the model or firmware.  Check other 7906 phones in the environment and see if they are reporting the same "issues" as the suspect phone.  Check firmware levels and see if there is a difference.


3. Check the network path.  If #1 and #2 are not definitive and you still are curious then check things like the interface counters on the port the phone connects to the uplink port from the access switch hosting the phone and any viable upstream neighber in the communication path.  If supported by your hardware, checking queuing stats to see if you are queuing in the first place. Check in both directions.  This is a deep dive exercise and I suggest you gather more evidence that you have an issue before spinning your wheels on it.  Though, I am like you I would want to know "why".


There is a possibility that it is the phone itself.  A simple test would be to swap the phone with another 7906.  I would test this out as follows:


1. Determine trends on the suspect phone.  For instance, are the symptoms reported on every call the phone has?  If so, that makes it easy on you.  The following approach makes more sense if you have a consistent behavior.


2. Take a 7906 and set it up in a controlled environment (near your office/cube).  Use the phone in a similar way as the suspect phone.  E.g. if you see phone calls lasting 1min or more have the issue.  Use the control phone for calls that are 1 min or more.  The idea is you find out how this "new" 7906 behaves on a network you choose.  Once you have your data. Swap phones with the suspect phone.


3. Monitor the "control" phone and see if the symptoms stay with the user.


4. Test out the "suspect" phone to see if the symptoms follow the phone.


I think you see where I am going with this.  Granted it isn't a definitive answer like "yeah, 7906's just do this"  but if I was dealing with this unknown, the above is the approach I would take.  More or less.


HTH.


Regards,

Bill

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
William Bell Wed, 02/17/2010 - 09:28
User Badges:
  • Purple, 4500 points or more

First, you have to keep in mind that CAR's CMR statistics should be taken as clues rather than as definitive proof of an issue.  I have seen jitter and packet loss be reported incorrectly by devices.  Sometimes this is due to a software defect so you can check the bug toolkit against your CUCM version and phone firmware.


In lieu of that, I would recommend the following:



1. See if you can localize the issue to the access network.   Check jitter/packet statistics for other phones that are on the same network as your suspect IP phone.  Prefereably on the same switch or even switch blade (if you use modular access switches).  If you see other phones reporting the same general experience then you should definitely dig deeper into the network.


2. See if you can localize the issue to the model or firmware.  Check other 7906 phones in the environment and see if they are reporting the same "issues" as the suspect phone.  Check firmware levels and see if there is a difference.


3. Check the network path.  If #1 and #2 are not definitive and you still are curious then check things like the interface counters on the port the phone connects to the uplink port from the access switch hosting the phone and any viable upstream neighber in the communication path.  If supported by your hardware, checking queuing stats to see if you are queuing in the first place. Check in both directions.  This is a deep dive exercise and I suggest you gather more evidence that you have an issue before spinning your wheels on it.  Though, I am like you I would want to know "why".


There is a possibility that it is the phone itself.  A simple test would be to swap the phone with another 7906.  I would test this out as follows:


1. Determine trends on the suspect phone.  For instance, are the symptoms reported on every call the phone has?  If so, that makes it easy on you.  The following approach makes more sense if you have a consistent behavior.


2. Take a 7906 and set it up in a controlled environment (near your office/cube).  Use the phone in a similar way as the suspect phone.  E.g. if you see phone calls lasting 1min or more have the issue.  Use the control phone for calls that are 1 min or more.  The idea is you find out how this "new" 7906 behaves on a network you choose.  Once you have your data. Swap phones with the suspect phone.


3. Monitor the "control" phone and see if the symptoms stay with the user.


4. Test out the "suspect" phone to see if the symptoms follow the phone.


I think you see where I am going with this.  Granted it isn't a definitive answer like "yeah, 7906's just do this"  but if I was dealing with this unknown, the above is the approach I would take.  More or less.


HTH.


Regards,

Bill

Actions

This Discussion