On 14 Mar 2014, at 14:51, Sean Bright <sean.bri...@gmail.com> wrote:
> On 3/14/2014 2:41 AM, Olle E. Johansson wrote: >> >> On 13 Mar 2014, at 22:13, Sean Bright <sean.bri...@gmail.com> 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. That was my next question. Yes, that's bad. > >> 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? 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. > >> 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. I disagree on "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? ;-) If this is how we are going to manage our product then I'm getting really worried. Are we controlling our own software? /O
-- _____________________________________________________________________ -- 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
