Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

VoIP 2.0 SP1 Polling and Stats issues

How are the values calculated for the Nodes?  When I get just a couple of sites with trouble (hub/spoke design) it seems to lower the MOS/Jitter for a node when really only a coupe of paths are the problem.  Seem like the path is really the alert source, not the Node.


Are the stats just averages for all paths to all nodes?  It is not really documented anywhere that I can see...  Also while I can VoIP SLA poll as often as 1 minute and collect stats, I cannot generate charts that are in intervals less than 5 minutes from the Orion interface.

0 Kudos
3 Replies
Level 19

The VoIP Sites stats ave averaged values from the associated call paths. So degradation in paths will lower scores for the associated sites.

If you want to see the one minute data you can use Report Writer. Orion does limit to five minute graphs.

0 Kudos


In presenting the data for the VoIP sites and paths, it seems to me that with a fully meshed and large implementation it is just simply very difficult to organize the data collected in such a way as to make it available in a reasonable fashion.  For such large configurations with dozens of paths (if not hundreds), graphical charts would be difficult to read and display...  Maybe a chart that lists only those sites that seem errant...

Like a chart that looks at the path's means for jitter, latency, drops, etc and plots graphs for those paths more than say 2 std dev from the mean...  (at least for the time range presented)

A deficiency for me now in the way this data is presented goes something like this...  When I find a node generates an alert that a value I set for a threshold (like 3.6 for MOS), there is no easy way to show the graphs for all the paths involved to rapidly see which one(s) are causing the lowered score.  The lower scores are often very transient and so the site overview charts many times are all green again when I fianlly get to look at the Site-View for the one which triggered the alert.

Currently I am using a hub/spoke design and when a spoke alerts, that is not too as hard to track, but when a hub reports the same issue it is much more time consuming...  The interface is pretty slow (maybe SP1 will help this some with less load on the SQL server) and the paths in both directions slow to display.  Also when I want to see the history in a graph for a particular site, I must do each path separately in both directions...  When I was fully meshed, it was much harder still...

Does this make more sense?  I am really just brain storming as to how better I might be able to get from problem to solution using the Orion tools...



0 Kudos

Thanks Andy.  I guess my thoughts are more along the lines of how the data is made available.  The Orion interface allows us to gerneate view, graphs, data, etc... via HTTP.  The Report writer requires that users have local login authority on the Orion servers as I understand it  That means Terminal Services and users leaving various processes running when they neglect to log off, etc...

That is the basic obstacle in this particular case.  VoIP statistics are obviously more time sensitive and so the extra resolution is useful, (at least to me) and we would rather not have folks logging in to the server to run reports...


Thank you,


0 Kudos