VoIP 2.0 SP1 Polling and Stats issues

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.

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,

-Corey

Andy,

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

 Thanks,

 -Corey