<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 13 Mar 2014, at 22:13, 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/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><div><br></div><div>Remember the bad configuration option "username" in chan_sip. I haven't seen many installations that hasn't filled that in just because it's there. 99.9% of the users did not bother to read documentation on it, unfortunately many Asterisk teachers did not understand it and explained it badly. It exists, people fill it in. Fortunately, in most places it did not hurt. A DNS server configuration in chan_pjsip will have the possibility to hurt badly.</div><div><br></div><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><div><br></div><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><div><br></div><div>/O</div></body></html>