On Wed, 2009-09-23 at 09:10 -0400, Raymond Dans wrote:
> Damian wrote:
> >Subject: Re: [sipX-dev] Site to Site Dialing Rule Question
> >
> ............
> >>
> >> Though that is the model that sipXconfig presents to the
> >user, I don't
> >> think that is how permissions are *implemented*. (Though I may be
> >> behind the times on this.) Yes, the call needs the correct
> >permission
> >> to activate the dialing rule (which is implemented in
> >mappingrules.xml).
> >> But once the call has been set up to forward to the gateway,
> >the call
> >> has to pass the tests in authrules.xml, which takes into account the
> >> destination of the call, and the permissions borne by the call, but
> >> does not know which dialing rule was responsible.
> >
> >The same gateway may appear many times in different tests.
> >While the code that authorizes the call does not (or should
> >not) care the end result is that you can certainly use the
> >same gateway in many rules and expect everything to work properly.
> >
>
> So then if this is correct then the setup I have (Site to Site rule uses
> same gateway as Long Distance rule) should work but does not because of
> the authrules.
>
> If we can agree that things should work in my setup, I'll put in a Jira
No, they probably should not work (given the current design).
Dale is correct - there are two independent decisions:
1. The fallbackrules matches some rule based on the dial string
(userpart of the request uri) and directs the call toward a
gateway _without_ checking whether or not the caller has
permission to make that call. Importantly - once a match is
found, no further possible matches are checked in fallbackrules.
Before the request can get to the gateway, it spirals back
through the proxy in a second authorization pass...
2. In the authorization pass, the target is checked again, based
first on the gateway address and then on the dial string. That
check produces a permission the caller must have for the request
to proceed. The matching is slightly different here - if the
target matchs the host part (the gateway) but not the user part
(the dial string), then the processor continues down the list to
find more matches. If no match is found, then no permission is
required and the request is allowed to proceed.
The 'NoAccess' that Raymond is seeing is a special "reject all gateway
calls" case at the end of authrules - it matches all gateway addresses
and any number pattern. This is the enforcement mechanism that prevents
an arbitrary number that doesn't match a pattern from being sent to a
gateway.
What Raymond probably did (guessing here, since we have not seen his
dial plan details) is to create two rules that sent to the same gateway,
but didn't always match the dial string patterns that could be directed
there. The fact that the target is a gateway means that it gets
included in the NoAccess rule at the bottom, and so his calls get
caught.
_______________________________________________
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/
