Martin Steinmann wrote: >> >> -----Original Message----- >> From: [email protected] > [mailto:sipx-dev->[email protected]] On Behalf Of Lawrence, > Scott (BL60:9D30) >> Sent: Tuesday, April 14, 2009 2:29 PM >> To: Krzeminski, Damian (BL60:9D30) >> Cc: [email protected] >> Subject: Re: [sipX-dev] should sipXconfig prevent adding redundant > proxies >if it thinks your network is not up for it? >> On Tue, 2009-04-14 at 13:22 -0400, Damian Krzeminski wrote: >> >>> I need some input here: >>> http://track.sipfoundry.org/browse/XCF-3616 >>> XCF-3616 suggests that if admin selected host name as a SIP domain > name >we >>> should stop them from adding redundant servers. Do people think we > should >>> really be that restrictive? It is conceivable that one prefers to >>> reconfigure DNS to make it work to changing SIP domain, right? >> Technically, it actually _should_ be possible to make it work to make >> one of the hosts and the domain have the same name. You _could_ >> configure SRV records that map host1.example.com to both >> host1.example.com and host2.example.com. In theory, a SIP UA should >> figure that out. But there's one of my favorite reminders: >> >> In theory, there's no difference between theory and practice; >> in practice, there is. >> >> I wouldn't bet that the majority of implementations wouldn't be > confused >> by hitting the same name as an SRV and an A record (I _think_ that >> sipXtackLib would do the right thing, but not having tested it, one >> never knows).
That's what I thought. >> >>> As far as I know SIP domain that is equal of your host name is not > even >the >>> default configuration. So if someone went through the troubles of >> changing >>> this default once why should we stop them from changing it again. >> Just because they changed it doesn't mean they knew what they were >> doing, or what it would cost them later. >> >>> Just to remind where I am coming from. sipXconfig is not a tool for >>> policing your network. If you happen to have invalid hostnames or > strange >>> DNS configured sipXconfig can point out the errors but it really > should >not >>> prevent you from configuring something. >> But remember who will have to answer the questions when what we allow >> doesn't work... I do get e-mails when sipXconfig prevents people from doing something. >> >> I would use the rule that we should restrict configurations to a subset >> of the theoretical possibilities that we believe is easily doable, will >> work well with most implementations, and still has the flexibility to > do >> things that actually need to be done. >> >> I think that in this case that rule would suggest that if someone wants >> to add a server, they first be told that they must reconfigure the >> domain name so that it is not identical to the first host name. >> > > Nicely put. The whole purpose of DNS/DHCP testing is to GUIDE the admin > towards a working config. It does not help if an expert can get it to > work. What we need to do is assist a less skilled installer to get it to > work without having to call for help. > --martin > I would think that that the best way of guiding people through non-HA to HA transition is to let them add a redundant server and only then tell them that DNS might be wrong (if it indeed is wrong). If we never let them to add the second server we will never have a chance of display a correct DNS configuration for it (DNS advisor works when the remote location is already added). Also SIP domain name (which by the way can have nothing to do with your host names) does not have to be something that you change lightly - this might be something that you shared with the world already. You might want the option to keep whatever name you selected (even if it turned out to be less than optimal choice) and still use HA. As of now I see more arguments against implementing such restrictions than for it. And since this is new feature we did not really have a real user feedback on it. I'll allow to keep this issue open: if I see people getting into trouble because of it, I'll take a patch. D. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
