[asterisk-dev] [Code Review] Fix SIP directmedia's use of ACL so that the directmedia reachability of peers is checked in a sensible fashion

jrose reviewboard at asterisk.org
Thu May 3 10:54:09 CDT 2012

This is an automatically generated e-mail. To reply, visit:

Review request for Asterisk Developers, Mark Michelson and Matt Jordan.


Prior to this patch, when comparing the host address to the allowable set of host addresses, the address of a peer would be compared to its own allowable address.  What we wanted with this was for the host to use the opposed peer's address for checking whether or not directmedia should be allowed.  This patch does that by getting the bridged channel's pvt and using that pvt's directmediaha to compare against to compare with.


  /branches/1.8/channels/chan_sip.c 364839 

Diff: https://reviewboard.asterisk.org/r/1899/diff


I had some test code in here while I was testing to make sure all of this made sense... it would basically print the acls being used for comparisons along with the ip addresses being compared.

2 phones with ip addresses and (shortened to 201 and 193).

Prior to the patch:

directmediadeny =
directmediapermit =

When 193 called 201, directmedia would be prevented because the ip address of 201 didn't match the directmediapermit address.  When 201 called 193, directmedia would work as no directmedia ha would actually be touched.

After the patch, 193 to 201 results in a connection because two comparisons occured, the first was 201 against 193's directmediaha (which was empty so that check passed).  The second was 193 against 201's directmediaha (which permits 193, so it passed direct media connected).

In a second scenario, the following was applied:

directmediapermit =
directmediadeny =

and another phone with a different IP address was added.

With the patch, calling 201 from 193 resulted in no directmedia connection when 193 compared against 201's directmediaha and was rejected.  The new phone passed the check since it used a different IP address.  Calls from 201 to 193 similarly didn't do a directmedia connection because of the same filter on 201 rejecting 193.

Unfortunately, video, text, and udptl couldn't really be checked, but the concepts are the same so it should probably be ok.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120503/6fce6449/attachment-0001.htm>

More information about the asterisk-dev mailing list