[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
mmichelson at digium.com
Wed May 2 13:44:43 CDT 2012
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:
> 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:
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()
> 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?
More information about the asterisk-dev