>
>
>-----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).
>
>> 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 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

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to