[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