> > > 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 disagree but I'll refrain from debating it further here. Following your advice, let's re-open this for 4.2 then and mark the inter-site transfers as a limitation for our 4.0 release. > 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. The big difference here is that clusters do not work across NATs whereas multi-sites do. > > 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. Signing off. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
