On Tue, 2010-03-02 at 08:55 -0500, Carolyn Beeton wrote: > After having a bit of a debate with myself in > http://track.sipfoundry.org/browse/XX-7783 I thought it better to get > some insight here :-) > > A couple of months ago, I set up my system with two Gateways to reach > another sipx system. One used dialplan 3xx and an Unmanaged Gateway to > connect directly. The other used dialplan 4xx and a sipXtrunk Gateway > to connect over TLS. This worked quite successfully for basic calls. > > However, recently problems turned up in various transfer and park > scenarios on the Unmanaged Gateway dialplan. These turned out to be due > to the itspname-callback entry in forwardingrules which is added > whenever a sipXtrunk Gateway is added, and causes sipxbridge to be > involved in all calls to that destination, even if they are dialled by a > rule that does not use that gateway. > > A similar issue was reported by Mark in > http://track.sipfoundry.org/browse/XX-5882. > > I think we should be able to set up dial rules to reach a given system > by different routes; but if we can't, then config should not allow two > gateways to be created with the same address.
As you point out, I'm already on record on this one - it should not work to configure the same thing using two different addresses. This is not just because I'm a purist (though I admit that I am) - it's because it doesn't work right, and making it work right is probably not possible. We use comparison of domain names to make a whole series of decisions that help prevent (potentially destructive) loops, and to make authorization decisions. Configuring the same thing in multiple ways can easily create undetectable configuration errors, including opening security holes. Automatically detecting when the administrator has done this is tough: given the flexibility of multiple addresses, multiple DNS names (including CNAMES and SRV records), and NATs, we just won't always be able to tell that A and B are really the same thing. So ultimately I think that the only protection is for us to say "don't do that - it hurts". _______________________________________________ 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/
