On Fri, Mar 14, 2014 at 9:51 AM, Sean Bright <[email protected]> wrote: > On 3/14/2014 2:41 AM, Olle E. Johansson wrote: > > > On 13 Mar 2014, at 22:13, Sean Bright <[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: > > Replace Asterisk's internal DNS facilities with PJLIB's, creating a > mandatory dependency on PJSIP. > 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. > 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. > FWIW: Adding a script to reload chan_pjsip into /etc/resolvconf/update.d (debian systems) should be a way to handle updates to asterisk when the nameserver changes. I'd rather go that route then trying to make asterisk / pjproject smart enough to detect 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 -- Paul Belanger | PolyBeacon, Inc. Jabber: [email protected] | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _____________________________________________________________________ -- 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
