On Mon, Mar 17, 2014 at 4:47 AM, Olle E. Johansson <[email protected]> wrote: > Friends, > After a bit of heated discussion I can try to make a conclusion from what I > see when the dust settled: > > - We are still in control of our own product and make our own decisions about > Asterisk architecture. Any arguments like "PJSIP has it so we have to enable > it" falls to the ground as not valid and disappear in a cloud of smoke. > > - No one has given any reasons why we should be able to configure DNS servers > in the PJSIP channel configuration, apart from Jared who wanted to let users > shoot themself in the feet. That is not the way I treat my users. I think > most of us now agree that we don't want to have that configuration item. > > - In the long run, having a DNS resolver embedded in a module is not a good > thing. Due to the PJSIP architecture, it's very hard to avoid. I've spoken > with several non-asterisk developers using PJSIP that have partly succeeded, > but not fully. We need to stress this to pjsip so that they can separate this > code in the future. > > - Having PJSIP parse /etc/resolv.conf is not a good thing. If that can't be > avoided, we need to monitor the file for updates from Asterisk and > reconfigure. > > Sorry for being a bit provocative, but some responses I got caused me to > become upset. I feel very strongly for keeping our architecture in control > and following the soul of Asterisk and the environment we run Asterisk in. > > I think that's all I see in the dust on the battleground. Any comments on > this? >
I've already spelled out my disagreements with your arguments here previously [1] [2] [3] [4]. I don't believe rehashing them again is going to be productive. Josh has removed the ability for an end user to configure the nameservers [5]. Asterisk will use the system ones if available - if those are not available, then the code will revert back to 'gethostbyname' style resolution. I think this is one of those situations in which we are going to have to agree to disagree. Disagreement is okay: being able to disagree means we can have healthy discussions. In this case, this is a change that I feel is immensely beneficial for end users, and which has minimal negative implications both for the architecture of Asterisk as well as for end users. You disagree with that; I respect your opinion. We are, however, going to move forward with this change. That does not mean the story is closed on DNS resolution in Asterisk or in chan_pjsip. As I said previously, I look forward to _any_ patch that improves DNS resolution capabilities in Asterisk. My fervent hope is that the DNS resolution capabilities in the core of Asterisk will reach a point where we can remove any reliance on the resolver in PJSIP. Doing so will be transparent to end users: as this change now has zero configuration capabilities, there will be no change from an end user's perspective on how resolution occurs. I certainly look forward to such a contribution from the Asterisk community. [1] http://lists.digium.com/pipermail/asterisk-dev/2014-March/065968.html [2] http://lists.digium.com/pipermail/asterisk-dev/2014-March/065990.html [3] http://lists.digium.com/pipermail/asterisk-dev/2014-March/066033.html [4] http://lists.digium.com/pipermail/asterisk-dev/2014-March/065992.html [5] http://lists.digium.com/pipermail/asterisk-dev/2014-March/066115.html -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- 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
