On 3/14/2014 2:41 AM, Olle E. Johansson wrote:
On 13 Mar 2014, at 22:13, Sean Bright <[email protected]
<mailto:[email protected]>> wrote:
On 3/13/2014 4:42 PM, Paul Belanger wrote:
+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.
In order to make this "channel agnostic" you have three (equally bad)
options:
1. Replace Asterisk's internal DNS facilities with PJLIB's, creating
a mandatory dependency on PJSIP.
2. 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.
3. 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.
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.
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?
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.
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. ;-)
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?
There are other options for asynch DNS too - like C-ARES. It's used in
a lot of products and embedded in Resiprocate.
Regarding changing PJSIP - it's just code, right? Why can't you change
PJSIP to use another API? That's a very strange statement.
You certainly could do that, but it's a lot of work for very little
gain. 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? ;-)
Sean
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
