[asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 14 Mar 2014, at 21:29, Jared Smith <jaredsmith at jaredsmith.net> wrote:

> 
> On Thu, Mar 13, 2014 at 3:34 PM, Olle E Johansson <reviewboard at asterisk.org> wrote:
> 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. 
> 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?
I haven't in any way said that it was a bad to go down this route, Jared.
> 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. 
> 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.
I haven't been against ANY DNS improvements - that is something other people have talked about, not me. I am primarily against including a way to configure DNS servers in a module of a larger product, and secondarily against including a DNS resolver in a module of the same product.  I have made those statements very clear in many mails and reviewboard - you even quoted it below.

>  
> 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. 
> OK, I can't speak about managing a "product", because this not a product to me. 
I don't get that.

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

You are writing the mail in a way that puts words in my mouth that hasn't been there. I am not against Asterisk improvements, or the PJSIP channel driver, DNS improvments or the way we manage our project. I am worried when developers add stuff that will break our architecture just because it is possible to do with a third party library and thus giving us a lot of future support. No one has stepped forward with a good reason to add DNS servers to the pjsip config file, a real problem it solves.

/O

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140316/200e230c/attachment.html>