<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 3:34 PM, Olle E Johansson <span dir="ltr"><<a href="mailto:reviewboard@asterisk.org" target="_blank">reviewboard@asterisk.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><pre style="white-space:pre-wrap;white-space:-moz-pre-wrap;white-space:-pre-wrap;white-space:-o-pre-wrap;word-wrap:break-word">
For every poorly designed bad feature I can think of I can find a large number of Asterisk users that want it. It's simply not a good argument. We create this software and need some sort of architecture when we do. </pre>
</blockquote><div>I think you're being a bit extreme here, Olle, and your email sounds (at least to my ears) as being quite demanding. You could use this same argument to shoot down *any* new feature or code. I know you're still focusing on Asterisk 1.8 and taking care of your paying customers (at least the last time we talked), but from my vantage point the whole reason we're going to down the road of pjsip and a new SIP channel driver is to have a better architecture, and these DNS changes are one part of a whole series of changes specifically designed to improve the architecture. What have the entire Asterisk 12 and 13 development cycles been about if not for improving our architecture?<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><pre style="white-space:pre-wrap;white-space:-moz-pre-wrap;white-space:-pre-wrap;white-space:-o-pre-wrap;word-wrap:break-word">
The current DNSmanager is broken in so many ways I can't even begin to describe it and it is not asynch, asterisk still stops if we're not getting an answer. </pre></blockquote><div>I agree one hundred percent. That's why it surprises me that you're coming out so vehemently about an improvement -- any improvement -- to the way we handle DNS. Now I agree that it's not ideal to have two different ways to resolve DNS in different parts of Asterisk -- but that being said, I think *any* improvement is a step in the right direction. Adding this code to pjsip doesn't make chan_sip any worse.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><pre style="white-space:pre-wrap;white-space:-moz-pre-wrap;white-space:-pre-wrap;white-space:-o-pre-wrap;word-wrap:break-word">
So why don't we continue down this path and include a full blown SIP proxy in chan_pjsip, and a HTTP server in chan_pjsip and much more. Let's add a b2bua to chan_pjsip while we're at it... ;-)</pre></blockquote>
<div><br></div><div>Now you're just being silly... we're not throwing a SIP proxy or a web server into chan_pjsip. We're simply trying to improve the way it handles DNS. As you have pointed out, DNS is a cruicial part of any SIP architecture, which is why I'd like to see some improvements in the way chan_pjsip handles DNS. Is it perfect? No. Is it better than what we have today? I think so. Am I personally willing to wait for "perfect" before I start using chan_pjsip? Nope...<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><pre style="white-space:pre-wrap;white-space:-moz-pre-wrap;white-space:-pre-wrap;white-space:-o-pre-wrap;word-wrap:break-word">
Even if it can ba done easily, doesn't mean it's right. We do need to manage our product. Adding the ability to configure a different set of DNS servers for a module or even a full server application is a bad thing. That's the first part we should not do. After that, we need to fix our DNS architecture. </pre>
</blockquote></div>OK, I can't speak about managing a "product", because this not a product to me. It's a tool that I happen to use. I leave it to others to productize it. On this mailing list, however, I feel we should focus on development of Asterisk as a toolset, and leave product discussions for other venues.<br>
<br>If you have suggestions on how to "fix our DNS architecture" as you say, in a way that is not only asynchronous, respects TTL (and refreshes results again once the TTLs have expired), handle SRV records correctly (including sorting), and solve the happy eyeballs/earballs problems, I'd love to see the code get incorporated into Asterisk. In the meantime, the proposal in front of us seems to be a step closer than what we have today. It may not be perfect, but I think there are more serious sins than allowing an end user to shoot themselves in the foot. (We already give them plenty of firearms and ammunition with the wide range of configuration options and files and modules available today.)<br>
<br>--<br></div><div class="gmail_extra">Jared Smith<br></div><div class="gmail_extra"><br><br></div></div>