Is anyone using the Dude for this ? If yes, how ?
I was thinking about writing a custom function that uses ping but I’m unable to find proper documentation on how to do this. Is there a doc on how to write functions ?
I hear you on this subject, we are starting to roll voice services and really want to utilise our existing dude environment to monitor for jitter and delay, but pinging is not goo enough and we need more.
Any suggestions would be appreciated.
Regards
Paul
Along those lines to make sure QoS is working in a Cisco phone system you can send a UDP packet (on any random high port) to a Cisco phone with a DSCP of EF(Expedited Forwarding) and it will reply with a “invalid port” but it will leave the DSCP set to EF. I have been wanting to build this probe to check the voice network and voice servers to find out if the EF tag is getting stripped. I have found QoS missing from quite a few places with Wireshark and I want a faster tool that I can chase down the QoS problems with.
Even just a (ping like) tool that could send a crafted UDP packet with DSCP-EF would be good since I just want to check real quick. Every packet generating tool I have played with is either too cumbersome or not suited to make a probe from. I am going to be doing more testing since I want to know if voice servers do the same thing as the phones do.
Anyhow back to the Jitter question… To actually test jitter you should only be using RTP and QoS. I don’t think the Dude can send that highly crafted of a packet but I would love to be proven wrong.
The problem with doing something with ICMP is there is no QoS and devices sometimes give it low priority to it. I know Cisco IP Phones do.
You might try a packet generator and use it through the External command. I haven’t found one I like yet.
Here is a good technical reference for what Jitter is… http://www.voiptroubleshooter.com/indepth/jittersources.html
Problem is that there are plenty of ways to monitor it realtime, but you can be 100% sure that when the customer rings up and complains about dropped audio or something you are not sitting in front of your console monitoring, the ideal outcome would be some sort of probe that can do the sort of monitoring that is needed for voip that will give you a history, so when customer A rings and complains about voice quality you can look at their link and see a problem, if it is of course your link, or you can say that it must be their equipment or something if you have a probe that says all is good at that point in time.
Paul