The current 18, 20, 21, 22 and master branches have the commit. Full details on the enhanced syntax and performance implications are in the configs/samples/manager.conf.sample file. Please take a look and let us know what you think
For the kinds of things I’ve done (admittedly not with heavy call traffic), it was easier to do all the event filtering within my own Python code. Basically I implement my own state machine, which lets me track the state of calls by matching up call IDs across events, look only for numbers of calls that I initiated and ignore the rest, that kind of thing. No need to write complicated Asterisk dialplan definitions.
I suspect filtering is more costly and it’s something someone would only do to ease the burden on the AMI program (or reduce the data file size). I have not seen a situation where there was too much info for the AMI program to handle but I too have only tested light call traffic (6 calls).
On a heavily loaded system the amount of events and traffic sent over the AMI connection can be extreme, thus filtering on the Asterisk side exists. If the AMI application can’t keep up then events can accumulate on the Asterisk side and you can reach a threshold where Asterisk starts having issues. If the filtering is fast enough on the Asterisk side, which this helps improve, then that raises the threshold a lot higher.
Is a trivial operation because we’re comparing the hash of the event name and not the string value. It’s basically comparing 2 integers. Previously it was a regular expression match which is quite expensive.