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

[Jared Smith]

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?

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


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


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

--
Jared Smith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140314/25ceb2d9/attachment.html>