Raymond wrote:
> I guess a few more details on my dial plan are required:
>
> 1. I have a Site To Site rule that uses Gateway A.
> This rule is to be used if a dial string with a prefix of 77 followed by
> 5 digits. The resultant dial string is the 5 digits to be sent over
> Gateway A. Being a Site to Site rule, there are no permissions on it.
>
> 2. I have a Long Distance rule that uses Gateway A.
> This rule is to be used if a dial string with a PSTN prefix of 9,
> followed by a Long Distance prefix of 1 and then 10 digits. The
> permission required to use this rule is the "Long Distance Dialing"
> permission.
>
> The authrules.xml file does not contain the dial pattern for the Site to
> Site dialing rule because it has no permission requirements.
> As a result of the dial pattern not being in the authrules.xml file, the
> catch all case (i.e. NoAccess) is used.
>
> I understand how the authrules file is used but it is correct to not
> have the Site to Site dial pattern in it?
This sort of configuration could be done by having authrules contain a
clause that matched the dial pattern from the site-to-site rule inside
the gateway A clause, and then specify no permissions for that one
(approximately) like this:
<hostMatch>
<hostPattern>GATEWAY-A</hostPattern>
<userMatch>
<userPattern>LONG-DISTANCE-DIAL-PATTERN</userPattern>
<permissionMatch>
<permission>LongDistance</permission>
</permissionMatch>
</userMatch>
<userMatch>
<userPattern>SITE-TO-SITE-DIAL-PATTERN</userPattern>
<permissionMatch/>
</userMatch>
</hostMatch>
(I'm pretty sure that works, but don't know if it's been tested)
This begs the question though - what did you think you were doing when
you did this? Is the idea to eventually use a gateway out of the other
system? If so, a better way to do it might be to use the (not yet
implemented) peer authentication so that the permissions enforcement is
on the peer system.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
