<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 14 Mar 2014, at 14:51, Sean Bright <<a href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/14/2014 2:41 AM, Olle E. Johansson
wrote:<br>
</div>
<blockquote cite="mid:807E841D-ADB8-4710-A031-805069F40FBE@edvina.net" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 13 Mar 2014, at 22:13, Sean Bright <<a moz-do-not-send="true" href="mailto:sean.bright@gmail.com">sean.bright@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/13/2014 4:42 PM, Paul
Belanger wrote:<br>
</div>
<blockquote cite="mid:CALLKq0SswDDWEXb9YiStCn2shSfA96VVwvq6vg8ppr+KctUnRA@mail.gmail.com" type="cite">
<pre wrap="">+1 with Dan. Comments aside on DNS functionality (I have opinions but
sitting this one out). Any functionality should be channel agnostic.
I too am a little concern'd that statement seems to have changed.</pre>
</blockquote>
<br>
In order to make this "channel agnostic" you have three
(equally bad) options:<br>
<ol>
<li>Replace Asterisk's internal DNS facilities with
PJLIB's, creating a mandatory dependency on PJSIP.</li>
<li>Roll a shiny new DNS API into Asterisk that supports
all address types (multiple results, weighting, etc.).
Bear in mind that PJSIP would not use this new API at
all, you would still need to create a PJLIB DNS resolver
and feed it the nameservers to use.<br>
</li>
<li>Use PJLIB's DNS interface if it is available,
otherwise fall back to Asterisk's current DNS
interface. This means that you are now maintaining two
separate interfaces and have to throw a layer of
abstraction in while you're at it. In fact, by adding
an abstraction layer you would force res_pjsip to then
unwrap and then re-wrap the abstraction just to get at
the necessary PJLIB data structures.<br>
</li>
</ol><p>Frankly, I don't see what all the hubbub is about. 99.9%
of users will never touch the nameservers configuration
option and it will behave exactly as if the system
resolver was being used.</p>
<div><br>
</div>
</div>
</blockquote>
If there is a configuration people will teach it and people will
use it. Later on, the sysadmin change /etc/resolv.conf since the
DNS servers used change and PJsip stops working. This is not a
good solution. There's no reason for that configuration option
at all. No one has stepped forward to explain a situation where
it would be needed, right?</div>
</blockquote>
<br>
Even if the 'nameservers' configuration option is removed and
Asterisk defaults to using the results of res_[n]init, an
administrator changing the name servers in /etc/resolv.conf will not
automatically be picked up by PJLIB's resolver. A reload of some
kind would still be required to pick up the changes.<br></div></blockquote>That was my next question. Yes, that's bad.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote cite="mid:807E841D-ADB8-4710-A031-805069F40FBE@edvina.net" type="cite">
<div>Regarding the resolver issue, I have no clear indication on
where to go. I only know I don't want to support a product with
multiple resolvers in it. I'm currently working on adding proper
SRV support to the old SIP driver and have been digging through
a lot of the DNS code. If you ask me today, anything will be
better, even a core dependency on PJSIP. ;-)</div>
</blockquote>
<br>
That's a bit like rearranging the deck chairs on the Titanic. Why
would anyone continue to use chan_sip when chan_pjsip is available?<br></div></blockquote>I am doing this for 1.8, there's no PJSIP available there. And until PJSIP is on par or ahead of chan_sip, it will be used in large production sites. Moving to PJSIP will require as much testing as moving to another platform.</div><div><br></div><div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote cite="mid:807E841D-ADB8-4710-A031-805069F40FBE@edvina.net" type="cite">
<div>There are other options for asynch DNS too - like C-ARES.
It's used in a lot of products and embedded in Resiprocate.</div>
<div><br>
</div>
<div>Regarding changing PJSIP - it's just code, right? Why can't
you change PJSIP to use another API? That's a very strange
statement.</div>
</blockquote>
<br>
You certainly could do that, but it's a lot of work for very little
gain. </div></blockquote>I disagree on "little gain".</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">It would mean continuing to maintain Asterisk's pjproject
fork until those changes were (hopefully) accepted upstream,
released, and then waiting for the rpm/deb packages to catch up.
Not to mention that someone would actually have to _do_ all of this
work. Could all volunteers please raise their hands? ;-)<br></div></blockquote><br></div><div>If this is how we are going to manage our product then I'm getting really worried. Are we controlling our own software?</div><div><br></div><div>/O</div><br></body></html>