>>>>> "JT" == John Todd <[EMAIL PROTECTED]> writes:
JT> Here's why I ask: I've had first-hand experience with JT> prioritized/weighted SRV records that cause serious problems. JT> Someone puts "10 10 _sip._udp.inside-proxy.foo.com" as their first JT> SRV record for foo.com, and "20 20 JT> _sip._udp.outside-proxy.foo.com" as their second preference SRV JT> record for foo.com. The host "inside-proxy" isn't reachable from JT> the Internet. Therefore, every call attempt that goes to their JT> domain goes first to a proxy that times out (wait... wait... JT> wait...) and then goes to the second one that completes. This JT> leads to unacceptable timeouts, and eventually leads to hard-coded JT> SRV record data put into a local resolving nameserver (can you say JT> "domain hijacking for operational purposes?") to avoid the delay. JT> This is Very Bad, and leads to User Anger. Isn't that a case of "Doctor, it hurts when I..."? I bet most SIP calls are between cooperating companies, so it should be possible to fix the problem correctly instead of doing workarounds. JT> I guess I'm saying that SRV record lookups should be able to be JT> turned off within Dial (which does exist today, despite my JT> approval of SRV lookups being "on" by default) and a function that JT> performs SRV lookups should be created so that the local JT> administrator can start to create a good/bad list of possible SRV JT> response entries for future use. This would not change the way * JT> behaves today; it would simply provide an alternative for the more JT> sophisticated administrator to control their own fate. I believe that is complication for no good reason. JT> I'm all for SRV automation behind-the-scenes as the default JT> behavior. However, I am less happy when there are no alternatives JT> to letting an administrator do things in a better way. You can just ignore the SRV record and define your own IP-based peer. JT> I'm sure I'm not alone here when I say that I dislike programs JT> that think they're smarter than me and won't let me change the JT> settings. I have never heard of a mail server which allows you to ignore certain MX records but obey the others. If you want to override MX for a certain domain, you create a policy for sending mail to that domain, and that ignores all the MX records. JT> Summary: I'd love to see a function that resolves and returns an JT> array-like set of SRV lookup results for a domain. Let the JT> administrator write a routine that then runs through the various JT> possible destinations. That on the other hand makes sense. If you keep all SRV priority handling out of asterisk itself, you can probably keep the asterisk code simple. There is a risk that the dial plan code gets too complicated though. /Benny _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
