[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

[Jonathan Rose]

----- Original Message -----
> From: "Mark Michelson" <mmichelson at digium.com>
> To: asterisk-dev at lists.digium.com
> Sent: Wednesday, May 2, 2012 1:44:43 PM
> Subject: Re: [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
> 
> 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.

Ah, thanks for that clarification.

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

Alright, the current plan has been revised to correct the behavior
within 1.8 and 10. Also, a new name will be used for the option in
trunk which will be usable along with the old name for this option.
The reasoning given for changing the name is because permit and deny
have an implicit connection to security while these options don't
actually involve security and instead are simply used to evaluate
whether or not a directmedia RTP path will be established.