[asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.
Sean Bright
sean.bright at gmail.com
Fri Mar 14 08:51:10 CDT 2014
On 3/14/2014 2:41 AM, Olle E. Johansson wrote:
>
> On 13 Mar 2014, at 22:13, Sean Bright <sean.bright at gmail.com
> <mailto:sean.bright at 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:
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140314/42d533e6/attachment-0001.html>
More information about the asterisk-dev
mailing list