[asterisk-dev] directmediapermit/deny doesn't work in any way approaching correct for any Asterisk version and is poorly named, so we should rework it in trunk

[Mark Michelson]

On 05/02/2012 01:09 PM, Jonathan Rose wrote:
> None of us really know how this feature ended up going through quite as dysfunctional as it was.  Here is a summary:
>
> directmediapermit/deny should allow a user to specify host addresses which block and allow the use of certain host addresses with directmedia if it would otherwise be available.  Allows supersede denies, so a user could specify something like:
> directmediadeny=0.0.0.0
> directmediapermit=192.168.10.203
> for a peer to allow that peer to use directmedia when making calls only to 192.168.10.203.
This isn't *quite* accurate. It's not that permits supersede denies, 
it's that the order that they are specified matters. The setup you just 
showed is for a typical whitelist approach. Another way is to use a 
blacklist approach like:

directmediapermit=0.0.0.0/0
directmediadeny=192.168.10.203/32

With this setup, you would initially permit everything, but the deny 
specified afterwards would supersede the previously established behavior 
of allowing everything.

> Meanwhile any calls to/from another host should keep Asterisk in the RTP path.
>
> Unfortunately, that isn't what it does right now at all.
>
> Currently, the permit/deny lists are only used for to the peer they are set for (calls coming from the peer aren't checked against that peer's permit/deny list at all)
This sentence is kind of hard to parse. If I understand you correctly, a 
peer's directmedia ACL is only checked if the call originates from the 
peer, correct? Both peers should have their directmedia ACLs checked 
based on what I see in ast_rtp_instance_bridge() in main/rtp_engine.c. 
ast_get_rtp_info() is called for both channels in the bridge, therefore 
it should not matter if the peer is the originator or recipient of the call.
>   and to make matters even more ridiculous, the address that is compared against the permit/deny list is the address belonging to the peer the list was set for. To simplify, on directmedia will be blocked in all cases where the peer has blocked itself from callid and it will be allowed for all cases where it has permitted itself for callid. This basically makes this a completely useless feature.
Yes, this is a glaring error. Peer B's media address should be run 
through Peer A's directmedia ACL and vice versa. The current approach 
does not work because only one endpoint is passed to the get_rtp_info() 
callback.
> This feature has never worked at any time since it was committed, so the current plan is to redesign the feature in trunk with a new name to the options (currently looking at directmediareachable/unreachable) and simply mark the option as broken in 1.8 and 10.  If anyone has any commentary about this, I'm all ears.
I think that if at all possible, the option should be fixed in 1.8 and 
10, even if it never actually worked. It was supposed to work, people 
expect it to work, and so we should go to the effort to make it work. 
Your approach for the release branches can differ from your plan for 
trunk to minimize invasiveness. Outline your suggested method of solving 
the problem and we can give feedback for whether the approach is usable 
for 1.8 and 10.

I don't think the feature necessarily has to be redesigned for trunk 
(i.e. I don't see a good reason to rename the option). Can't you just 
make it so the directmediapermit and directmediadeny options do what 
they are documented to do?

Mark!