[asterisk-dev] [Code Review] On demand AMI event filters

[kobaz]

> On 2011-05-24 03:15:16, Olle E Johansson wrote:
> > I would rather see 
> > 
> > Action: AmiFilter
> > Operation: Add
> > 
> > That would open for "Operation: Delete" to delete active filters. I am not sure that you need the strange syntax with two colons, since the filter is always for events. Or am I wrong?
> > 
> > /O
> 
> FeyFre wrote:
>     > I am not sure that you need the strange syntax with two colons
>     Event filter works also for non-"Event" header, i.e if I have filter "eventfilter=!UserEvent: bla-bla-bla" in my manager.conf I shall not receive AMI events which has "UserEvent: bla-bla-bla" line among headers. So "double colon"-ed syntax is legal and useful(just retested on r315054).
> 
> Olle E Johansson wrote:
>     Ok then :-) Thanks for the explanation.

I was thinking about delete operations too, but I'm not sure how they would work just yet. Good point about making room for additional operations within filters for the same command name.

You could either delete all filters, or delete by filter pattern, but if someone had two identical filters it would delete both (which is probably good?).  Code would need to be added to store the pattern in the filter list.  I personally would like to also see an Operation: List, so you could see your filters.  I'll probably add that in.

What I also like to see is a more explicit attachment of filter patterns.  For example, instead of filtering on individual event lines like this:
Filter: UserEvent: foo
Filter: UserEvent: baz
Filter: Channel: SIP/bar.*
Filter: Channel: SIP/bing.*

The above will whitelist UserEvent foo, and UserEvent baz, and whitelist channels SIP/bar, SIP/bing.

Maybe there can be something called a FilterSet, where only if that entire group of filters is matched, will the event be blacklisted or whitelisted.

There would need to be a new ami header processing command that will return a list of all headers matching. __astman_get_header_all() or something like that.
This would fundamentally break clients that build commands using hashes (Like I do, using perl hashes).

I would like to be able to do:
Action: AmiFilter
Operation: AddFilterSet
FilterSet: UserEvent: foo
FilterSet: Channel: SIP/bar.*
(Give me only foo user events on SIP/bar.*)

Action: AmiFilter
Operation: AddFilterSet
FilterSet: UserEvent: baz
FilterSet: Channel: SIP/bing.*
(Give me only baz user events on SIP/bing.*)

In order to not fundamentally break clients using hashes, there are other options:
Action: AmiFilter
Operation: AddFilterSet
FilterSet(1): UserEvent: baz
FilterSet(2): Channel: SIP/bing.*

Or, my least favorite
Action: AmiFilter
Operation: AddFilterSet
FilterSet: UserEvent: baz,Channel: SIP/bing.*

The above poses a problem if the pattern you want to filter actually has a comma in it.


- kobaz


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1228/#review3599
-----------------------------------------------------------


On 2011-05-23 21:19:14, kobaz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1228/
> -----------------------------------------------------------
> 
> (Updated 2011-05-23 21:19:14)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> There is already support for white and black filters for AMI events in manager.conf, but they are defined statically.
> 
> It would be really great to be able to log in and add filters on the fly for just the current session.
> 
> 
> Diffs
> -----
> 
>   trunk/main/manager.c 320708 
> 
> Diff: https://reviewboard.asterisk.org/r/1228/diff
> 
> 
> Testing
> -------
> 
> ----------------------
> Test 1
> ----------------------
> 
> Log into AMI, events: all
> 
> Action: UserEvent
> UserEvent: foo
> MyValue: bar
> 
> (userevent recieved)
> 
> Action: FilterAdd
> Filter: !UserEvent: foo
> 
> Action: UserEvent
> UserEvent: foo
> MyValue: bar
> 
> (no foo userevent event received)
> 
> ----------------------
> Test 2
> ----------------------
> 
> Log into AMI session 1, events: all
> Log into AMI session 2, events: all
> 
> AMI session 1:
>   Action: FilterAdd
>   Filter: Event: PeerStatus
> 
>   (only peerstatus events received)
> 
> AMI session 2:
>   (all events received)
> 
> 
> Thanks,
> 
> kobaz
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110524/9c0e45a9/attachment.htm>