Scott wrote: >Subject: Re: [sipX-dev] Site to Site Dialing Rule Question > >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. > >
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? Raymond _______________________________________________ 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/
