> > Let's try to understand all the implications. > > Implementing a gateway type that would generate authrules > > matching any dialed number severly limits the permission checking. > > At the moment if you use a gateway in 2 different rules and > > if those rules require different permission authrules > > generated by sipXconfig will handle it correctly. > > > > If we introduce gateways that skip user part you'll get into > > situations that calls are restricted or allowed based on the > > permissions of the first rule that is using that gateway > > which in many cases will be incorrect. > > I think your observations are correct and although one could perhaps > question the need for having multiple dialplans to a remote sipXecs in > real life deployments, given that it is a theoretical possibility, we > should deal with the situation if we can afford it. > > Perhaps the best way to deal with the situation is to go back to my > initial proposal which is to keep the authrules the same but simply > exclude the gateway from the 'NoAccess' clause. That way, permission > checking for multiple diaplans to the same remote sipXecs gateway will > continue to work as they do today. The only difference is that if a > userpart does not fall into the range of any configured dialplan using > the gateway, the request will be allowed and routed to that gateway. > The expectation is that the remote gateway, being a sipXecs, will be > configured with the proper permissions to restrict access its protected > resources and challenge requests as required.
That's no better than not matching the user part at all. I think that this entire subject is too complicated to introduce in 4.0, and that we should not take too much time with it now so that we don't consume resources needed to get 4.0 out the door. If you want multiple sites and you want transfers to work in the sort of ping-pong you describe, then the way to do that in 4.0 is to make the sites a cluster that is administered as one system. That will work. One of the things we've discussed for 4.2 is to work out a model for how to administer federated systems (which is my label for the configuration you started with, Robert - multiple systems with separate administration but some close relationship, possibly including a unified dial plan). Let's defer this discussion until then. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
