Hi David,
The first thing I would suggest doing is browsing through the recent events from the sensor for any which may have been triggered by traffic coming from addresses in use by your VoIP system. In the absence of any relevant events, you can create an Event Action Override for Risk Rating 0-100 to add the Produce Alert action, setup a few more calls and then check the event store again. The EAO will cause all signatures, even those without the Produce Alert action configured by default, to log events to the event store. When you're done testing, disable the EAO to prevent wasting resources on the sensor.
If you still don't see any events, it's possible that the sensor is oversubscribed despite the fact that your capture may appear to be well under the 600Mb documented for that model. The 600Mb metric is measured using a sensor with completely default signature sets and transfering "media rich" traffic (i.e. a lower number of higher volume streams), while in promiscuous mode. The "transactional" rating is 500Mb, under the same conditions. Voice is generally considered "transactional" traffic. When deploying a sensor inline, a very rough estimate is to shave 20% off the expected performance, so you'd end up with 400Mb in this case. This would be the theoretical maximum of the aggregate traffic in both directions. If you start altering the default signatures that Cisco provides the performance can begin to drop off rapidly depending on the complexity and number of signatures you tune..
If, after double check in the signatures firing, defaulting the signature set and checking the traffic rate (which should be monitored at peak times, or at least those during which you are consistently experiencing the problem) you are still unable to explain the degredation, it may be worth it to open a TAC case.
Best Regards,
JT
