Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

> On March 18, 2014, 12:43 p.m., wdoekes wrote:
> > /branches/12/res/res_pjsip/config_system.c, lines 200-206
> > 
> >
> > No ao2_ref(discovered_nameservers, -1); here?

Fixed in SVN, cheers!


- Joshua


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11269
---


On March 17, 2014, 10:53 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 17, 2014, 10:53 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_system.c 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[wdoekes]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11269
---


I realise this was committed already, but:


/branches/12/res/res_pjsip/config_system.c


No ao2_ref(discovered_nameservers, -1); here?


- wdoekes


On March 17, 2014, 10:53 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 17, 2014, 10:53 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_system.c 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/
---

(Updated March 17, 2014, 5:53 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 410795


Bugs: ASTERISK-23435
https://issues.asterisk.org/jira/browse/ASTERISK-23435


Repository: Asterisk


Description
---

This change adds a configuration option for setting nameservers to be used by 
the PJSIP DNS client. If this option is not set then the system nameservers are 
retrieved and used instead.

This also allows the nameservers to be changed by doing a reload.

In case others are wondering as Olle was:

PJLIB-Util (part of pjproject) provides a DNS client which can optionally (but 
is highly suggested) to be used with PJSIP. It provides asynchronous DNS, SRV 
lookups, multiple record support, etc. Right now this isn't enabled so we are 
simply doing A/ record lookups. The reason it's not enabled is that 
explicit nameservers *must* be provided to it when enabling it. It will not use 
the system ones by itself. The change up on reviewboard enables it by default 
using the system nameservers it finds, but with the ability to override or 
completely disable it if a user wants. The reason I also provide reload 
functionality is that people in #asterisk-dev expressed a concern that users 
may change nameservers but don't want to restart Asterisk, which is 
understandable. 


Diffs
-

  /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
  /branches/12/res/res_pjsip/config_system.c 410470 
  /branches/12/res/res_pjsip/config_global.c 410470 
  /branches/12/res/res_pjsip.c 410470 
  /branches/12/main/dns.c 410470 
  /branches/12/include/asterisk/dns.h 410470 
  /branches/12/CHANGES 410470 

Diff: https://reviewboard.asterisk.org/r/3343/diff/


Testing
---

Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
and confirmed that the DNS client was disabled. Set to auto (explicitly and by 
default) and confirmed that the system nameservers were used.


Thanks,

Joshua Colp

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Sean Bright]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11257
---

Ship it!


Ship It!

- Sean Bright


On March 17, 2014, 1:15 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 17, 2014, 1:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_system.c 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11253
---

Ship it!


There has been a long and healthy debate on this patch on the mailing list. 
However, after that debate, I still feel this patch is in the best interest of 
Asterisk and its users - as such, I'm moving to Ship It.

As I've mentioned in several e-mails on this subject, any patch that improves 
the core DNS code in Asterisk such that reliance on PJSIP's DNS resolution 
capabilities is no longer necessary would be a welcome addition. If that patch 
is ever written for the Asterisk core, we should revisit this patch and find a 
way to move chan_pjsip over to the core's DNS resolver API.

- Matt Jordan


On March 17, 2014, 8:15 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 17, 2014, 8:15 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_system.c 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/
---

(Updated March 17, 2014, 1:15 p.m.)


Review request for Asterisk Developers.


Changes
---

Remove the ability to configure nameservers. The code will use the system ones 
if available and if not then resort to system resolution as it previously did. 
CHANGES file has been updated accordingly.


Bugs: ASTERISK-23435
https://issues.asterisk.org/jira/browse/ASTERISK-23435


Repository: Asterisk


Description
---

This change adds a configuration option for setting nameservers to be used by 
the PJSIP DNS client. If this option is not set then the system nameservers are 
retrieved and used instead.

This also allows the nameservers to be changed by doing a reload.

In case others are wondering as Olle was:

PJLIB-Util (part of pjproject) provides a DNS client which can optionally (but 
is highly suggested) to be used with PJSIP. It provides asynchronous DNS, SRV 
lookups, multiple record support, etc. Right now this isn't enabled so we are 
simply doing A/ record lookups. The reason it's not enabled is that 
explicit nameservers *must* be provided to it when enabling it. It will not use 
the system ones by itself. The change up on reviewboard enables it by default 
using the system nameservers it finds, but with the ability to override or 
completely disable it if a user wants. The reason I also provide reload 
functionality is that people in #asterisk-dev expressed a concern that users 
may change nameservers but don't want to restart Asterisk, which is 
understandable. 


Diffs (updated)
-

  /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
  /branches/12/res/res_pjsip/config_system.c 410470 
  /branches/12/res/res_pjsip/config_global.c 410470 
  /branches/12/res/res_pjsip.c 410470 
  /branches/12/main/dns.c 410470 
  /branches/12/include/asterisk/dns.h 410470 
  /branches/12/CHANGES 410470 

Diff: https://reviewboard.asterisk.org/r/3343/diff/


Testing
---

Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
and confirmed that the DNS client was disabled. Set to auto (explicitly and by 
default) and confirmed that the system nameservers were used.


Thanks,

Joshua Colp

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Jeremy Lainé]

On 03/13/2014 10:13 PM, Sean Bright wrote:
> 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.
>

If you do decide you want a cross-platform, asynchronous DNS API which is not 
tied to
pjlib, you might consider c-ares (of libcurl / wireshark / node.js fame):

http://c-ares.haxx.se/

Just my two cents.

Jeremy
-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 14 Mar 2014, at 21:29, Jared Smith  wrote:

> 
> On Thu, Mar 13, 2014 at 3:34 PM, Olle E Johansson  
> wrote:
> For every poorly designed bad feature I can think of I can find a large 
> number of Asterisk users that want it. It's simply not a good argument. We 
> create this software and need some sort of architecture when we do. 
> I think you're being a bit extreme here, Olle, and your email sounds (at 
> least to my ears) as being quite demanding. You could use this same argument 
> to shoot down *any* new feature or code.  I know you're still focusing on 
> Asterisk 1.8 and taking care of your paying customers (at least the last time 
> we talked), but from my vantage point the whole reason we're going to down 
> the road of pjsip and a new SIP channel driver is to have a better 
> architecture, and these DNS changes are one part of a whole series of changes 
> specifically designed to improve the architecture.  What have the entire 
> Asterisk 12 and 13 development cycles been about if not for improving our 
> architecture?
I haven't in any way said that it was a bad to go down this route, Jared.
> The current DNSmanager is broken in so many ways I can't even begin to 
> describe it and it is not asynch, asterisk still stops if we're not getting 
> an answer. 
> I agree one hundred percent.  That's why it surprises me that you're coming 
> out so vehemently about an improvement -- any improvement -- to the way we 
> handle DNS.  Now I agree that it's not ideal to have two different ways to 
> resolve DNS in different parts of Asterisk -- but that being said, I think 
> *any* improvement is a step in the right direction.  Adding this code to 
> pjsip doesn't make chan_sip any worse.
I haven't been against ANY DNS improvements - that is something other people 
have talked about, not me. I am primarily against including a way to configure 
DNS servers in a module of a larger product, and secondarily against including 
a DNS resolver in a module of the same product.  I have made those statements 
very clear in many mails and reviewboard - you even quoted it below.

>  
> Even if it can ba done easily, doesn't mean it's right. We do need to manage 
> our product. Adding the ability to configure a different set of DNS servers 
> for a module or even a full server application is a bad thing. That's the 
> first part we should not do. After that, we need to fix our DNS architecture. 
> OK, I can't speak about managing a "product", because this not a product to 
> me. 
I don't get that.

> It's a tool that I happen to use.  I leave it to others to productize it.  On 
> this mailing list, however, I feel we should focus on development of Asterisk 
> as a toolset, and leave product discussions for other venues.
> 
> If you have suggestions on how to "fix our DNS architecture" as you say, in a 
> way that is not only asynchronous, respects TTL (and refreshes results again 
> once the TTLs have expired), handle SRV records correctly (including 
> sorting), and solve the happy eyeballs/earballs problems, I'd love to see the 
> code get incorporated into Asterisk.  In the meantime, the proposal in front 
> of us seems to be a step closer than what we have today.  It may not be 
> perfect, but I think there are more serious sins than allowing an end user to 
> shoot themselves in the foot.  (We already give them plenty of firearms and 
> ammunition with the wide range of configuration options and files and modules 
> available today.)

You are writing the mail in a way that puts words in my mouth that hasn't been 
there. I am not against Asterisk improvements, or the PJSIP channel driver, DNS 
improvments or the way we manage our project. I am worried when developers add 
stuff that will break our architecture just because it is possible to do with a 
third party library and thus giving us a lot of future support. No one has 
stepped forward with a good reason to add DNS servers to the pjsip config file, 
a real problem it solves.

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Jared Smith]

On Thu, Mar 13, 2014 at 3:34 PM, Olle E Johansson
wrote:

> For every poorly designed bad feature I can think of I can find a large 
> number of Asterisk users that want it. It's simply not a good argument. We 
> create this software and need some sort of architecture when we do.
>
> I think you're being a bit extreme here, Olle, and your email sounds (at
least to my ears) as being quite demanding. You could use this same
argument to shoot down *any* new feature or code.  I know you're still
focusing on Asterisk 1.8 and taking care of your paying customers (at least
the last time we talked), but from my vantage point the whole reason we're
going to down the road of pjsip and a new SIP channel driver is to have a
better architecture, and these DNS changes are one part of a whole series
of changes specifically designed to improve the architecture.  What have
the entire Asterisk 12 and 13 development cycles been about if not for
improving our architecture?

> The current DNSmanager is broken in so many ways I can't even begin to 
> describe it and it is not asynch, asterisk still stops if we're not getting 
> an answer.
>
> I agree one hundred percent.  That's why it surprises me that you're
coming out so vehemently about an improvement -- any improvement -- to the
way we handle DNS.  Now I agree that it's not ideal to have two different
ways to resolve DNS in different parts of Asterisk -- but that being said,
I think *any* improvement is a step in the right direction.  Adding this
code to pjsip doesn't make chan_sip any worse.


> So why don't we continue down this path and include a full blown SIP proxy in 
> chan_pjsip, and a HTTP server in chan_pjsip and much more. Let's add a b2bua 
> to chan_pjsip while we're at it... ;-)
>
>
Now you're just being silly... we're not throwing a SIP proxy or a web
server into chan_pjsip.  We're simply trying to improve the way it handles
DNS.  As you have pointed out, DNS is a cruicial part of any SIP
architecture, which is why I'd like to see some improvements in the way
chan_pjsip handles DNS.  Is it perfect?  No.  Is it better than what we
have today?  I think so.  Am I personally willing to wait for "perfect"
before I start using chan_pjsip?  Nope...


> Even if it can ba done easily, doesn't mean it's right. We do need to manage 
> our product. Adding the ability to configure a different set of DNS servers 
> for a module or even a full server application is a bad thing. That's the 
> first part we should not do. After that, we need to fix our DNS architecture.
>
> OK, I can't speak about managing a "product", because this not a product
to me.  It's a tool that I happen to use.  I leave it to others to
productize it.  On this mailing list, however, I feel we should focus on
development of Asterisk as a toolset, and leave product discussions for
other venues.

If you have suggestions on how to "fix our DNS architecture" as you say, in
a way that is not only asynchronous, respects TTL (and refreshes results
again once the TTLs have expired), handle SRV records correctly (including
sorting), and solve the happy eyeballs/earballs problems, I'd love to see
the code get incorporated into Asterisk.  In the meantime, the proposal in
front of us seems to be a step closer than what we have today.  It may not
be perfect, but I think there are more serious sins than allowing an end
user to shoot themselves in the foot.  (We already give them plenty of
firearms and ammunition with the wide range of configuration options and
files and modules available today.)

--
Jared Smith
-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Paul Belanger]

On Fri, Mar 14, 2014 at 1:19 PM, Matthew Jordan  wrote:
> On Fri, Mar 14, 2014 at 9:02 AM, Olle E. Johansson  wrote:
>>
>> 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?
>>
>
> Of course we are controlling our own software! The problem of "I need
> something in this library, and adding it brings me out of step with
> the upstream until they accept it" is certainly not new to Asterisk's
> usage of PJSIP. It's the same problem every open source project has
> faced when they depend on another open source project. And there is,
> of course, an easy solution: write a patch to the open source project
> you depend on, submit it upstream, and in the meantime deal with the
> differences.
>
> Is that a bit harder than embedding a library or writing the entire
> library yourself? Of course. Does it mean that some changes that you
> might make if you "owned the code" you instead choose not to make
> because you have to submit it upstream? Sure. That's part of the cost
> of depending on someone else's code. But the benefits of using a
> library far outweigh the disadvantages: the fact that in a year or so
> of time we were able to produce a functioning SIP channel driver with
> 95% of the features in chan_sip and additional features besides should
> be proof enough of the benefit.
>
+1 external lib for SIP support please. I still believe it was the
right choice to make, just means new battles to be had getting new
code into upstream.  What I don't want to see us do is fork said
library and start maintaining it, because of difficulties getting code
merged.

I cannot speak to pjsip or the DNS patch, since I have not used them
yet. But, if pjproject supports it, why not use it?  If we can expose
DNS for other channel drivers, great, but that should be a discussion
point.  Either way, I'm happy Sean and Josh figure out how not to
directly ready from /etc/resolv.conf for nameservers, that was some
ugly code :D

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matthew Jordan]

On Fri, Mar 14, 2014 at 12:49 PM, Joshua Colp  wrote:
> Matthew Jordan wrote:
>
> 
>
>
>>> My problem is when I get arguments like "it's there in PJIP so we
>>> have to use it" or "we can't do anything because of PJSIP".
>>
>>
>> That's not my argument at all.
>>
>> My argument is thus:
>>
>> * PJSIP provides DNS resolution that far exceeds what is capable in
>> Asterisk today and does so in an obtrusive fashion. It has no
>> negative side effects to the rest of Asterisk. It's three lines of
>> code to enable it. I want to turn it on. * If Asterisk's core DNS
>> catches up - and hopefully surpasses PJSIP - then by all means, let
>> us as a project submit a patch to PJSIP that makes their DNS
>> resolution pluggable. That would allow us to modify the res_pjsip
>> stack to use Asterisk's DNS support.
>
>
> Inobtrusive, not obtrusive. Two different words.
>

I should stick to smaller words.

-- 
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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

Matthew Jordan wrote:




My problem is when I get arguments like "it's there in PJIP so we
have to use it" or "we can't do anything because of PJSIP".


That's not my argument at all.

My argument is thus:

* PJSIP provides DNS resolution that far exceeds what is capable in
Asterisk today and does so in an obtrusive fashion. It has no
negative side effects to the rest of Asterisk. It's three lines of
code to enable it. I want to turn it on. * If Asterisk's core DNS
catches up - and hopefully surpasses PJSIP - then by all means, let
us as a project submit a patch to PJSIP that makes their DNS
resolution pluggable. That would allow us to modify the res_pjsip
stack to use Asterisk's DNS support.


Inobtrusive, not obtrusive. Two different words.

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matthew Jordan]

On Fri, Mar 14, 2014 at 9:29 AM, Olle E. Johansson  wrote:
>
> On 14 Mar 2014, at 15:22, Sean Bright  wrote:
>
>> On 3/14/2014 10:02 AM, Olle E. Johansson wrote:
 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?
>>
>> I'm not sure why you are getting worried.  If you would like to improve the 
>> DNS resolver within Asterisk are you not free to do so?
>
> And I'm doing it.
>
> My problem is when I get arguments like "it's there in PJIP so we have to use 
> it" or "we can't do anything because of PJSIP".

That's not my argument at all.

My argument is thus:

 * PJSIP provides DNS resolution that far exceeds what is capable in
Asterisk today and does so in an obtrusive fashion. It has no negative
side effects to the rest of Asterisk. It's three lines of code to
enable it. I want to turn it on.
 * If Asterisk's core DNS catches up - and hopefully surpasses PJSIP -
then by all means, let us as a project submit a patch to PJSIP that
makes their DNS resolution pluggable. That would allow us to modify
the res_pjsip stack to use Asterisk's DNS support.

Working code - code that functions, is well tested, and is
maintainable - is the currency of open source projects. We have that
today with the patch on review board.

> PJSIP doesn't do happy eyeballs, doesn't do SIP outbound and misses a lot of 
> features that we do need. If we are locked down waiting for them and can not 
> control our own fate as a product, we are in really bad shape.

Those aren't strictly functions of PJSIP.

(1) Happy eyeballs would be something that the res_pjsip stack would
handle. It has the ability to inform the lower level stack whether to
use IPv6 or IPv4. It could initiate a dialog to both address schemes
and cancel the loser. The fact that res_pjsip chooses not to do this
is a function of Asterisk, not PJSIP.
(2) PJSIP does support the parts of SIP outbound that it needs to
support [1]. In 12.1.0, we started moving res_pjsip in the direction
to make use of PJSIP's support for the various SIP outbound extensions
by adding Path header support [2]. PJSUA - produced by Teluu and
bundled in PJPROJECT - is built on top of the parts of PJSIP that our
stack is built on - and it supports SIP outbound [3] (with a few
caveats that are specific to PJSUA). Asterisk could support all of SIP
outbound if the application logic to do so was built in the res_pjsip
stack. This is a problem in our project, not theirs.
(3) So far, I have not run into a single feature that we could not
implement using this stack. One may exist. If so, we have an easy
solution: PJSIP is an open source project. As good open source
contributors, we can submit a patch that adds it to PJSIP, then add
said functionality to Asterisk. As I mentioned previously, this may be
a bit harder than if all of the logic was baked into Asterisk, but
that's a problem that all library dependencies face.

[1] https://trac.pjsip.org/repos/ticket/1020?version=1
[2] 
http://blogs.digium.com/2014/03/07/asterisk-12-1-0-new-features-asterisk-users/
[3] 
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2010-December/012225.html

> I am not saying they are not doing a good job in PJSIP, but if I was a 
> product manager for Asterisk I would not like having so little control of one 
> of the most important modules.

I am perfectly happy with the control I have over Asterisk as well as
the functionality PJSIP provides.

-- 
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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matthew Jordan]

On Fri, Mar 14, 2014 at 9:02 AM, Olle E. Johansson  wrote:
>
> 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?
>

Of course we are controlling our own software! The problem of "I need
something in this library, and adding it brings me out of step with
the upstream until they accept it" is certainly not new to Asterisk's
usage of PJSIP. It's the same problem every open source project has
faced when they depend on another open source project. And there is,
of course, an easy solution: write a patch to the open source project
you depend on, submit it upstream, and in the meantime deal with the
differences.

Is that a bit harder than embedding a library or writing the entire
library yourself? Of course. Does it mean that some changes that you
might make if you "owned the code" you instead choose not to make
because you have to submit it upstream? Sure. That's part of the cost
of depending on someone else's code. But the benefits of using a
library far outweigh the disadvantages: the fact that in a year or so
of time we were able to produce a functioning SIP channel driver with
95% of the features in chan_sip and additional features besides should
be proof enough of the benefit.

-- 
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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 14 Mar 2014, at 16:57, Paul Belanger  wrote:

> On Fri, Mar 14, 2014 at 10:29 AM, Olle E. Johansson  wrote:
>> 
>> On 14 Mar 2014, at 15:22, Sean Bright  wrote:
>> 
>>> On 3/14/2014 10:02 AM, Olle E. Johansson wrote:
> 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?
>>> 
>>> I'm not sure why you are getting worried.  If you would like to improve the 
>>> DNS resolver within Asterisk are you not free to do so?
>> 
>> And I'm doing it.
>> 
>> My problem is when I get arguments like "it's there in PJIP so we have to 
>> use it" or "we can't do anything because of PJSIP".
>> 
>> PJSIP doesn't do happy eyeballs, doesn't do SIP outbound and misses a lot of 
>> features that we do need. If we are locked down waiting for them and can not 
>> control our own fate as a product, we are in really bad shape.
>> 
>> I am not saying they are not doing a good job in PJSIP, but if I was a 
>> product manager for Asterisk I would not like having so little control of 
>> one of the most important modules.
>> 
> I cannot remember if we talked about this at astridevcon or not, but
> by using an external library you are some what committed to using
> there feature set.  Which, is fine IMO.  However, as new features are
> needed / added, we'd ideally work with upstream to get them merged up.
> I'm pretty happy we finally got all the patches to pjproject merged by
> teluu, but some what concerned about the troubles other people have
> had getting code merged (I think ajprojects).  I'm not sure if Digium
> had to get some support agreement or not but at the end of the day, we
> are dependent on teluu's workflow process.

Which means we are loosing the competitive edge as well as our control.
Which was something I was worried about all along.

Anyway, I am sure we can speak with the PJSIP guys about this and fix it 
in the right way. We still need to have as a goal to have a good and clean
architecture and be a good citizen in the Unix/Linux servers we run. 

The PJSIP stack was written primarily for phones, not servers, which from time 
to time
shows. This is one area where the architecture is bad for a server. 

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Paul Belanger]

On Fri, Mar 14, 2014 at 10:29 AM, Olle E. Johansson  wrote:
>
> On 14 Mar 2014, at 15:22, Sean Bright  wrote:
>
>> On 3/14/2014 10:02 AM, Olle E. Johansson wrote:
 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?
>>
>> I'm not sure why you are getting worried.  If you would like to improve the 
>> DNS resolver within Asterisk are you not free to do so?
>
> And I'm doing it.
>
> My problem is when I get arguments like "it's there in PJIP so we have to use 
> it" or "we can't do anything because of PJSIP".
>
> PJSIP doesn't do happy eyeballs, doesn't do SIP outbound and misses a lot of 
> features that we do need. If we are locked down waiting for them and can not 
> control our own fate as a product, we are in really bad shape.
>
> I am not saying they are not doing a good job in PJSIP, but if I was a 
> product manager for Asterisk I would not like having so little control of one 
> of the most important modules.
>
I cannot remember if we talked about this at astridevcon or not, but
by using an external library you are some what committed to using
there feature set.  Which, is fine IMO.  However, as new features are
needed / added, we'd ideally work with upstream to get them merged up.
I'm pretty happy we finally got all the patches to pjproject merged by
teluu, but some what concerned about the troubles other people have
had getting code merged (I think ajprojects).  I'm not sure if Digium
had to get some support agreement or not but at the end of the day, we
are dependent on teluu's workflow process.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 14 Mar 2014, at 15:22, Sean Bright  wrote:

> On 3/14/2014 10:02 AM, Olle E. Johansson wrote:
>>> 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?
> 
> I'm not sure why you are getting worried.  If you would like to improve the 
> DNS resolver within Asterisk are you not free to do so?

And I'm doing it. 

My problem is when I get arguments like "it's there in PJIP so we have to use 
it" or "we can't do anything because of PJSIP". 

PJSIP doesn't do happy eyeballs, doesn't do SIP outbound and misses a lot of 
features that we do need. If we are locked down waiting for them and can not 
control our own fate as a product, we are in really bad shape.

I am not saying they are not doing a good job in PJSIP, but if I was a product 
manager for Asterisk I would not like having so little control of one of the 
most important modules.

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Sean Bright]

On 3/14/2014 10:02 AM, Olle E. Johansson wrote:
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?


I'm not sure why you are getting worried.  If you would like to improve 
the DNS resolver within Asterisk are you not free to do so?


--
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Paul Belanger]

On Fri, Mar 14, 2014 at 9:51 AM, Sean Bright  wrote:
> On 3/14/2014 2:41 AM, Olle E. Johansson wrote:
>
>
> On 13 Mar 2014, at 22:13, Sean Bright  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: paul.belan...@polybeacon.com | 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 14 Mar 2014, at 14:51, Sean Bright  wrote:

> On 3/14/2014 2:41 AM, Olle E. Johansson wrote:
>> 
>> On 13 Mar 2014, at 22:13, Sean Bright  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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Sean Bright]

On 3/14/2014 2:41 AM, Olle E. Johansson wrote:


On 13 Mar 2014, at 22:13, Sean Bright > 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
-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 13 Mar 2014, at 23:34, Matthew Jordan  wrote:

> (1) This is not "new" functionality - in the sense that we have not
> written some amazing new functionality in either the core or a
> res_pjsip* module and only want to use it one place. PJSIP itself
> already provides DNS resolution. We just want to turn it on.

1. Please do not enable configuration of DNS servers for PJSIP. Always use the 
system configuration.
2. Just because it is in the library doesn't mean it is a good thing for 
Asterisk.
3. I have not questioned whether Josh is doing a good job or not.

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 13 Mar 2014, at 22:13, Sean Bright  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?

Remember the bad configuration option "username" in chan_sip. I haven't seen 
many installations that hasn't filled that in just because it's there. 99.9% of 
the users did not bother to read documentation on it, unfortunately many 
Asterisk teachers did not understand it and explained it badly. It exists, 
people fill it in. Fortunately, in most places it did not hurt. A DNS server 
configuration in chan_pjsip will have the possibility to hurt badly.

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. ;-)

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.

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 13 Mar 2014, at 21:42, Paul Belanger  wrote:

> On Thu, Mar 13, 2014 at 4:15 PM, Dan Austin  wrote:
>> Matt wrote:
>> 
>> Not including this change does not seem to buy us anything, save for some
>> semblance of architectural purity. While I would love for there to be only
>> one way to perform DNS resolution, that feels like a long term goal - and
>> sacrificing the practicality of delivering a feature that a large number of
>> Asterisk users have wanted for an extremely long time doesn't feel worth it
>> to me.
>> 
>> 
>> 
>> I am indifferent to PJSIP and have no intent to use it any time soon, so my
>> critic is not of
>> 
>> that channel driver.  In times not so long past if a developer offered a new
>> feature for one
>> 
>> of the second-class channels or apps they stood a good chance being told to
>> rewrite it to
>> 
>> be channel agnostic,  that it should (had to) be coded in such a way that
>> all channels would
>> 
>> benefit.  It is kind of amusing to see that turned around to not apply to
>> the new kid on the block.
>> 
> +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.

Well, I am not. First Matt kept chocking me by questioning a lot of our old
rules that seemed carved in stone. But in the end, we have something that
will lead to a much better product - which is the important thing. At some point
we will have to ask ourselves as a project about all these old rules - are they
still meaningful? Matt has done a lot of good for the project and the product
by doing this.

In this case though, I think he's wrong ;-)

I do agree with you a bit. While it is important to remember and follow
the core architecture of asterisk and try to be channel-agnostic, we also
have to ask ourselves what is going to be important a few years from now.
Will and ISDN-inspired core take us there? 

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matt Jordan]

> On March 13, 2014, 10:31 a.m., Olle E Johansson wrote:
> > We really should NOT add this code. Instead, we should clean up the code so 
> > all of Asterisk use the same resolver and relies on the system 
> > configuration. Having a separate DNS resolver, maybe even using a separate 
> > DNS server in the PJSIP channel is not a good solution and should be 
> > avoided at all cost. 
> > 
> > The good thing with this review is that it opened my eyes of some stuff in 
> > PJSIP that should not be there in the way we use it.
> 
> Matt Jordan wrote:
> DNS support in Asterisk has had problems for a long time and is something 
> that I think we would all like to see improved upon. The state of such 
> support as it exists in the core today is limited: modules and the core can 
> either use dnsmgr – which only gives you a single IP address result but does 
> make an attempt at querying and managing the DNS records – or they can use 
> ast_gethostbyname, which is a wrapper around a reentrant version of 
> gethostbyname. In the case of the former, users get a small (albeit limited) 
> benefit of having the records be managed internally; in the case of the 
> latter users only get the standard gethostbyname behavior. Neither option 
> provides asynchronous DNS querying, nor does either option providethe ability 
> to handle multiple SRV records.
> 
> The situation is the way it is today not because parsing and returning 
> multiple DNS records is particularly hard, or because properly weighting the 
> results is extremely difficult. Even making the querying of records 
> asynchronous is doable. While not trivial changes, they are well understood 
> problems and the API in dns.h/srv.h/dnsmgr.h could be modified accordingly. 
> The hard part is making use of the DNS information.
> 
> The legacy IP based channel drivers in Asterisk are not structured in 
> such a fashion that the location of the thing that Asterisk communicates with 
> is separate from the IP address. This was an unfortunate design decision; 
> separating out the concept of location from the IP address is now extremely 
> non-trivial. I can't stress this enough: it is an incredibly large task to go 
> do this work – particularly when we consider the size and complexity of those 
> channel drivers. Unfortunately, chan_sip and chan_iax2 are both places where 
> this would be beneficial, but also cases where making use of multiple SRV 
> records or asynchronous DNS would be extremely challenging.
> 
> That gets to the crux of the problem: even if we had the world's best DNS 
> resolver in the Asterisk core, the vast majority of places in Asterisk that 
> you would like to make use of it would not easily be able to do so.
> 
> There is, of course, benefit to having better DNS support in the core of 
> Asterisk outside of those channel drivers. New things would be able to make 
> use of it easier, and improvements in the DNS support would be shared by all 
> things that use it. I think it would be great to see patches that improve the 
> DNS support in the core. This should include asynchronous querying, multiple 
> SRV records, as well as other cool kinds of things such as DANE. At the same 
> time, since the vast majority of existing channel drivers can't make use of 
> that information, it is of admittedly limited benefit unless other changes 
> take place.
> 
> This is, unfortunately, one of those places where making use of a third 
> party stack does make things more difficult for us. Despite all the benefits 
> PJSIP brings - and it is a lot! - there are bound to be some downsides, and 
> its integration with its DNS resolver could be considered one of them. I can 
> see two possible approaches available for us to go make use of a core DNS 
> resolver:
> 
> (1) Modify PJSIP to support a pluggable DNS resolver. The PJSIP endpoint 
> does support having a DNS resolver be registered to it; unfortunately, today 
> this is an opaque structure that the endpoint uses with 
> pjlib-util/resolver.h. We would have to provide a shim between 
> pj_dns_resolver and the core resolver, and then update PJSIP to directly use 
> the shim – with callbacks between a PJSIP version of the shim and 
> pj_dns_resolver used internally in that project by default. This is doable, 
> but again, not a trivial amount of work. Since the changes would be 
> substantial, we would be forking PJSIP (again) and pushing our changes 
> up-stream (again). This is not something we should shy away from when 
> necessary, but it is something we should keep in mind when making substantial 
> changes in that project.
> (2) We could eschew any usage of PJSIP's DNS resolution by simply 
> performing all of the resolution ourselves and pre-populating the PJSIP 
> message structs in the res_pjsip* modules with the data. We _think_ that this 
> would work: PJSIP should detect that it already has an address and not bother 
> with any resolutio

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matthew Jordan]

On Thu, Mar 13, 2014 at 4:13 PM, Sean Bright  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.
>

To build on Sean's sentiments:

(1) This is not "new" functionality - in the sense that we have not
written some amazing new functionality in either the core or a
res_pjsip* module and only want to use it one place. PJSIP itself
already provides DNS resolution. We just want to turn it on.

(2) Disregarding obtaining the nameservers, enabling the DNS
resolution as we want it to be used could be all of the following
code:

pj_dns_resolver *resolver;

if (!pjsip_endpt_get_resolver(ast_sip_get_pjsip_endpoint())) {
pjsip_endpt_create_resolver(ast_sip_get_pjsip_endpoint(), &resolver);
pjsip_endpt_set_resolver(ast_sip_get_pjsip_endpoint(), resolver);
}

Josh did more of this because he's doing a Good Job. It's
certainly fine to look at how we get to those lines of code; maybe we
should not allow the user to specify the nameservers. At the end of
the day, however, those few lines of code enable asynchronous DNS,
multiple SRV records, and all the fanciness that comes with them.
Achieving the same functionality in any other channel driver is
thousands of lines of code. The scale of the problem is not the same
across the code base. Often, when people have proposed some generic
new functionality and only implemented it in a single channel driver,
we do push for its usage everywhere when the level of effort is the
same across all channel drivers: that isn't the case here.

(3) Even if this were a general purpose change - and as Sean pointed
out, it is not - many other general purpose frameworks have been
introduced in Asterisk and have not been globally applied to every
channel driver - the Configuration Framework, Sorcery, and others come
to mind. This is for good reason: the act of introducing them into an
existing channel driver would create more problems, i.e., regressions,
than they would solve. Going forward, we attempt to use these
frameworks where possible - but not at the sake of hurting existing
users of Asterisk. This is clearly one of those cases: as I pointed
out, implementing the kind of DNS resolution this provides (assuming
we had something that provided it) in chan_sip or chan_iax2 is a gut
and rewrite of those channel drivers. There is _no_ way such an
implementation wouldn't be a substantial risk to users of those
drivers.

(4) Applying a new feature everywhere is not a policy [1]. It *is* a
guideline (of a type which until recently, wasn't even written down
[2]). Policies are great; guidelines are great. They should be
followed - but not to the overall detriment of the project. Adhering
to the letter of the law while ignoring the spirit is not something
I'll ever advocate.

[1] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
[2] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist

-- 
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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Sean Bright]

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.


-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Paul Belanger]

On Thu, Mar 13, 2014 at 4:15 PM, Dan Austin  wrote:
> Matt wrote:
>
> Not including this change does not seem to buy us anything, save for some
> semblance of architectural purity. While I would love for there to be only
> one way to perform DNS resolution, that feels like a long term goal - and
> sacrificing the practicality of delivering a feature that a large number of
> Asterisk users have wanted for an extremely long time doesn't feel worth it
> to me.
>
>
>
> I am indifferent to PJSIP and have no intent to use it any time soon, so my
> critic is not of
>
> that channel driver.  In times not so long past if a developer offered a new
> feature for one
>
> of the second-class channels or apps they stood a good chance being told to
> rewrite it to
>
> be channel agnostic,  that it should (had to) be coded in such a way that
> all channels would
>
> benefit.  It is kind of amusing to see that turned around to not apply to
> the new kid on the block.
>
+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.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Dan Austin]

Matt wrote:

Not including this change does not seem to buy us anything, save for some 
semblance of architectural purity. While I would love for there to be only one 
way to perform DNS resolution, that feels like a long term goal – and 
sacrificing the practicality of delivering a feature that a large number of 
Asterisk users have wanted for an extremely long time doesn't feel worth it to 
me.

I am indifferent to PJSIP and have no intent to use it any time soon, so my 
critic is not of
that channel driver.  In times not so long past if a developer offered a new 
feature for one
of the second-class channels or apps they stood a good chance being told to 
rewrite it to
be channel agnostic,  that it should (had to) be coded in such a way that all 
channels would
benefit.  It is kind of amusing to see that turned around to not apply to the 
new kid on the block.

Dan
-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E Johansson]

> On March 13, 2014, 4:31 p.m., Olle E Johansson wrote:
> > We really should NOT add this code. Instead, we should clean up the code so 
> > all of Asterisk use the same resolver and relies on the system 
> > configuration. Having a separate DNS resolver, maybe even using a separate 
> > DNS server in the PJSIP channel is not a good solution and should be 
> > avoided at all cost. 
> > 
> > The good thing with this review is that it opened my eyes of some stuff in 
> > PJSIP that should not be there in the way we use it.
> 
> Matt Jordan wrote:
> DNS support in Asterisk has had problems for a long time and is something 
> that I think we would all like to see improved upon. The state of such 
> support as it exists in the core today is limited: modules and the core can 
> either use dnsmgr – which only gives you a single IP address result but does 
> make an attempt at querying and managing the DNS records – or they can use 
> ast_gethostbyname, which is a wrapper around a reentrant version of 
> gethostbyname. In the case of the former, users get a small (albeit limited) 
> benefit of having the records be managed internally; in the case of the 
> latter users only get the standard gethostbyname behavior. Neither option 
> provides asynchronous DNS querying, nor does either option providethe ability 
> to handle multiple SRV records.
> 
> The situation is the way it is today not because parsing and returning 
> multiple DNS records is particularly hard, or because properly weighting the 
> results is extremely difficult. Even making the querying of records 
> asynchronous is doable. While not trivial changes, they are well understood 
> problems and the API in dns.h/srv.h/dnsmgr.h could be modified accordingly. 
> The hard part is making use of the DNS information.
> 
> The legacy IP based channel drivers in Asterisk are not structured in 
> such a fashion that the location of the thing that Asterisk communicates with 
> is separate from the IP address. This was an unfortunate design decision; 
> separating out the concept of location from the IP address is now extremely 
> non-trivial. I can't stress this enough: it is an incredibly large task to go 
> do this work – particularly when we consider the size and complexity of those 
> channel drivers. Unfortunately, chan_sip and chan_iax2 are both places where 
> this would be beneficial, but also cases where making use of multiple SRV 
> records or asynchronous DNS would be extremely challenging.
> 
> That gets to the crux of the problem: even if we had the world's best DNS 
> resolver in the Asterisk core, the vast majority of places in Asterisk that 
> you would like to make use of it would not easily be able to do so.
> 
> There is, of course, benefit to having better DNS support in the core of 
> Asterisk outside of those channel drivers. New things would be able to make 
> use of it easier, and improvements in the DNS support would be shared by all 
> things that use it. I think it would be great to see patches that improve the 
> DNS support in the core. This should include asynchronous querying, multiple 
> SRV records, as well as other cool kinds of things such as DANE. At the same 
> time, since the vast majority of existing channel drivers can't make use of 
> that information, it is of admittedly limited benefit unless other changes 
> take place.
> 
> This is, unfortunately, one of those places where making use of a third 
> party stack does make things more difficult for us. Despite all the benefits 
> PJSIP brings - and it is a lot! - there are bound to be some downsides, and 
> its integration with its DNS resolver could be considered one of them. I can 
> see two possible approaches available for us to go make use of a core DNS 
> resolver:
> 
> (1) Modify PJSIP to support a pluggable DNS resolver. The PJSIP endpoint 
> does support having a DNS resolver be registered to it; unfortunately, today 
> this is an opaque structure that the endpoint uses with 
> pjlib-util/resolver.h. We would have to provide a shim between 
> pj_dns_resolver and the core resolver, and then update PJSIP to directly use 
> the shim – with callbacks between a PJSIP version of the shim and 
> pj_dns_resolver used internally in that project by default. This is doable, 
> but again, not a trivial amount of work. Since the changes would be 
> substantial, we would be forking PJSIP (again) and pushing our changes 
> up-stream (again). This is not something we should shy away from when 
> necessary, but it is something we should keep in mind when making substantial 
> changes in that project.
> (2) We could eschew any usage of PJSIP's DNS resolution by simply 
> performing all of the resolution ourselves and pre-populating the PJSIP 
> message structs in the res_pjsip* modules with the data. We _think_ that this 
> would work: PJSIP should detect that it already has an address and not bother 
> with any resolution

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matt Jordan]

> On March 13, 2014, 10:31 a.m., Olle E Johansson wrote:
> > We really should NOT add this code. Instead, we should clean up the code so 
> > all of Asterisk use the same resolver and relies on the system 
> > configuration. Having a separate DNS resolver, maybe even using a separate 
> > DNS server in the PJSIP channel is not a good solution and should be 
> > avoided at all cost. 
> > 
> > The good thing with this review is that it opened my eyes of some stuff in 
> > PJSIP that should not be there in the way we use it.

DNS support in Asterisk has had problems for a long time and is something that 
I think we would all like to see improved upon. The state of such support as it 
exists in the core today is limited: modules and the core can either use dnsmgr 
– which only gives you a single IP address result but does make an attempt at 
querying and managing the DNS records – or they can use ast_gethostbyname, 
which is a wrapper around a reentrant version of gethostbyname. In the case of 
the former, users get a small (albeit limited) benefit of having the records be 
managed internally; in the case of the latter users only get the standard 
gethostbyname behavior. Neither option provides asynchronous DNS querying, nor 
does either option providethe ability to handle multiple SRV records.

The situation is the way it is today not because parsing and returning multiple 
DNS records is particularly hard, or because properly weighting the results is 
extremely difficult. Even making the querying of records asynchronous is 
doable. While not trivial changes, they are well understood problems and the 
API in dns.h/srv.h/dnsmgr.h could be modified accordingly. The hard part is 
making use of the DNS information.

The legacy IP based channel drivers in Asterisk are not structured in such a 
fashion that the location of the thing that Asterisk communicates with is 
separate from the IP address. This was an unfortunate design decision; 
separating out the concept of location from the IP address is now extremely 
non-trivial. I can't stress this enough: it is an incredibly large task to go 
do this work – particularly when we consider the size and complexity of those 
channel drivers. Unfortunately, chan_sip and chan_iax2 are both places where 
this would be beneficial, but also cases where making use of multiple SRV 
records or asynchronous DNS would be extremely challenging.

That gets to the crux of the problem: even if we had the world's best DNS 
resolver in the Asterisk core, the vast majority of places in Asterisk that you 
would like to make use of it would not easily be able to do so.

There is, of course, benefit to having better DNS support in the core of 
Asterisk outside of those channel drivers. New things would be able to make use 
of it easier, and improvements in the DNS support would be shared by all things 
that use it. I think it would be great to see patches that improve the DNS 
support in the core. This should include asynchronous querying, multiple SRV 
records, as well as other cool kinds of things such as DANE. At the same time, 
since the vast majority of existing channel drivers can't make use of that 
information, it is of admittedly limited benefit unless other changes take 
place.

This is, unfortunately, one of those places where making use of a third party 
stack does make things more difficult for us. Despite all the benefits PJSIP 
brings - and it is a lot! - there are bound to be some downsides, and its 
integration with its DNS resolver could be considered one of them. I can see 
two possible approaches available for us to go make use of a core DNS resolver:

(1) Modify PJSIP to support a pluggable DNS resolver. The PJSIP endpoint does 
support having a DNS resolver be registered to it; unfortunately, today this is 
an opaque structure that the endpoint uses with pjlib-util/resolver.h. We would 
have to provide a shim between pj_dns_resolver and the core resolver, and then 
update PJSIP to directly use the shim – with callbacks between a PJSIP version 
of the shim and pj_dns_resolver used internally in that project by default. 
This is doable, but again, not a trivial amount of work. Since the changes 
would be substantial, we would be forking PJSIP (again) and pushing our changes 
up-stream (again). This is not something we should shy away from when 
necessary, but it is something we should keep in mind when making substantial 
changes in that project.
(2) We could eschew any usage of PJSIP's DNS resolution by simply performing 
all of the resolution ourselves and pre-populating the PJSIP message structs in 
the res_pjsip* modules with the data. We _think_ that this would work: PJSIP 
should detect that it already has an address and not bother with any resolution 
if we did that. This has several obvious drawbacks however: (a) we take the 
burden of when and how to do resolution out of the library, which often has 
better knowledge of when to do this action than the res_pjsi

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E Johansson]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11170
---


We really should NOT add this code. Instead, we should clean up the code so all 
of Asterisk use the same resolver and relies on the system configuration. 
Having a separate DNS resolver, maybe even using a separate DNS server in the 
PJSIP channel is not a good solution and should be avoided at all cost. 

The good thing with this review is that it opened my eyes of some stuff in 
PJSIP that should not be there in the way we use it.

- Olle E Johansson


On March 13, 2014, 11:42 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 13, 2014, 11:42 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/pjsip_configuration.c 410470 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/configs/pjsip.conf.sample 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Michael L. Young]

- Original Message -
> From: "Olle E. Johansson" 
> To: "Asterisk Developers Mailing List" 

> So we have yet another internal resolver? Is that a good thing? Why
> are we not using the system resolver?
> 
> We need to have some direction here. I think adding yet another DNS
> resolver is bad and will make it hard to add functions like
> DNSsec/DANE support. Making it possible for one piece of asterisk to
> use another DNS resolver is poor design, we should not open up for
> that.  The number of debug problems and runtime issues I see is
> reaching infinity. "I can ping this server, but the sip channel
> can't reach it" is just a start.
> 
> Is there a way we can either avoid using yet another resolver, or
> since this is propably better - switch all of Asterisk to use it and
> we'll get asynch DNS everywhere?
> 
> I can understand why a library like PJsip have support for this, in
> some cases it's the only way when writing clients like soft phones.
> That doesn't mean we have to expose it. We can still select and
> decide for ourselves about our design.
> 
> Summary
> - Don't add yet another DNS resolver randomly
> - Don't allow using different DNS servers in parts of a server app
> and please don't allow anyone to configure anything else than the
> system resolvers in a server application.

I understand what Olle is getting at and I agree with it.  Why do we want 
res_pjsip using something different from the rest of Asterisk?  Everything 
should be using the same DNS resolver.  Otherwise, we are opening up a can of 
worms here when it comes to supporting Asterisk and trying to troubleshoot DNS 
issues.

This just doesn't seem like the right direction to go here.

Michael

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 13 Mar 2014, at 12:06, Joshua Colp  wrote:

> Olle E. Johansson wrote:
>> 
>> On 13 Mar 2014, at 11:42, Joshua Colp > > wrote:
>> 
>>> In case others are wondering as Olle was:
>>> 
>>> PJLIB-Util (part of pjproject) provides a DNS client which can
>>> optionally (but is highly suggested) to be used with PJSIP. It
>>> provides asynchronous DNS, SRV lookups, multiple record support,
>>> etc. Right now this isn't enabled so we are simply doing A/
>>> record lookups. The reason it's not enabled is that explicit
>>> nameservers *must* be provided to it when enabling it. It will not
>>> use the system ones by itself. The change up on reviewboard enables
>>> it by default using the system nameservers it finds, but with the
>>> ability to override or completely disable it if a user wants. The
>>> reason I also provide reload functionality is that people in
>>> #asterisk-dev expressed a concern that users may change nameservers
>>> but don't want to restart Asterisk, which is understandable.
>> 
>> Interesting to get answer in another channel... For both of us.
>> 
>> My question still stands - why would anyone want one part of Asterisk
>> use other DNS servers than the rest of Asterisk and the rest of the
>> system? If there is something wrong with the system resolver, that
>> needs to be fixed.
>> 
>> I do not see the need for us to have a configuration option here.
>> Someone else may have a good reason for it.
> 
> I can't guarantee that the code which automatically determines and gets the 
> nameservers from the system will work on all platforms. It's using res_init / 
> res_ninit which, depending on the implementation, parses resolv.conf and 
> stores the information. I think it *should* work but for cases where it won't 
> the ability to manually set them is there. For most people you don't even 
> need to know it exists or set it.

So we have yet another internal resolver? Is that a good thing? Why are we not 
using the system resolver?

We need to have some direction here. I think adding yet another DNS resolver is 
bad and will make it hard to add functions like DNSsec/DANE support. Making it 
possible for one piece of asterisk to use another DNS resolver is poor design, 
we should not open up for that.  The number of debug problems and runtime 
issues I see is reaching infinity. "I can ping this server, but the sip channel 
can't reach it" is just a start.

Is there a way we can either avoid using yet another resolver, or since this is 
propably better - switch all of Asterisk to use it and we'll get asynch DNS 
everywhere?

I can understand why a library like PJsip have support for this, in some cases 
it's the only way when writing clients like soft phones. That doesn't mean we 
have to expose it. We can still select and decide for ourselves about our 
design. 

Summary
- Don't add yet another DNS resolver randomly
- Don't allow using different DNS servers in parts of a server app and please 
don't allow anyone to configure anything else than the system resolvers in a 
server application.

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11158
---



/branches/12/res/res_pjsip.c


New parameter => alembic update


- Matt Jordan


On March 13, 2014, 5:42 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 13, 2014, 5:42 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/pjsip_configuration.c 410470 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/configs/pjsip.conf.sample 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Sean Bright]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/#review11157
---

Ship it!


Looks good to me.  Now if only we could have it automatically update with 
/etc/resolv.conf is changed...


/branches/12/res/res_pjsip/config_global.c


The comment and function name are stale, but this was already resolved in 
your development branch.  Just pointing it out.


- Sean Bright


On March 13, 2014, 10:42 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 13, 2014, 10:42 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/pjsip_configuration.c 410470 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/configs/pjsip.conf.sample 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

Olle E. Johansson wrote:


On 13 Mar 2014, at 11:42, Joshua Colp mailto:reviewbo...@asterisk.org>> wrote:


In case others are wondering as Olle was:

PJLIB-Util (part of pjproject) provides a DNS client which can
optionally (but is highly suggested) to be used with PJSIP. It
provides asynchronous DNS, SRV lookups, multiple record support,
etc. Right now this isn't enabled so we are simply doing A/
record lookups. The reason it's not enabled is that explicit
nameservers *must* be provided to it when enabling it. It will not
use the system ones by itself. The change up on reviewboard enables
it by default using the system nameservers it finds, but with the
ability to override or completely disable it if a user wants. The
reason I also provide reload functionality is that people in
#asterisk-dev expressed a concern that users may change nameservers
but don't want to restart Asterisk, which is understandable.


Interesting to get answer in another channel... For both of us.

My question still stands - why would anyone want one part of Asterisk
 use other DNS servers than the rest of Asterisk and the rest of the
 system? If there is something wrong with the system resolver, that
needs to be fixed.

I do not see the need for us to have a configuration option here.
Someone else may have a good reason for it.


I can't guarantee that the code which automatically determines and gets 
the nameservers from the system will work on all platforms. It's using 
res_init / res_ninit which, depending on the implementation, parses 
resolv.conf and stores the information. I think it *should* work but for 
cases where it won't the ability to manually set them is there. For most 
people you don't even need to know it exists or set it.


--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 13 Mar 2014, at 11:42, Joshua Colp  wrote:

> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 

Interesting to get answer in another channel... For both of us.

My question still stands - why would anyone want one part of Asterisk use other 
DNS servers than the rest of Asterisk and the rest of the system? If there is 
something wrong with the system resolver, that needs to be fixed.

I do not see the need for us to have a configuration option here. Someone else 
may have a good reason for it.

/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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

Olle E. Johansson wrote:


On 12 Mar 2014, at 19:53, Joshua Colp mailto:reviewbo...@asterisk.org>> wrote:


This change adds a configuration option for setting nameservers to
be used by the PJSIP DNS client. If this option is not set then the
system nameservers are retrieved and used instead.

This also allows the nameservers to be changed by doing a reload.


Why is this a good thing?


I've now also placed my response on reviewboard in case anyone else 
comes along it and wants an extended explanation.


Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3343/
---

(Updated March 13, 2014, 10:42 a.m.)


Review request for Asterisk Developers.


Changes
---

Based on the question from Olle update description.


Bugs: ASTERISK-23435
https://issues.asterisk.org/jira/browse/ASTERISK-23435


Repository: Asterisk


Description (updated)
---

This change adds a configuration option for setting nameservers to be used by 
the PJSIP DNS client. If this option is not set then the system nameservers are 
retrieved and used instead.

This also allows the nameservers to be changed by doing a reload.

In case others are wondering as Olle was:

PJLIB-Util (part of pjproject) provides a DNS client which can optionally (but 
is highly suggested) to be used with PJSIP. It provides asynchronous DNS, SRV 
lookups, multiple record support, etc. Right now this isn't enabled so we are 
simply doing A/ record lookups. The reason it's not enabled is that 
explicit nameservers *must* be provided to it when enabling it. It will not use 
the system ones by itself. The change up on reviewboard enables it by default 
using the system nameservers it finds, but with the ability to override or 
completely disable it if a user wants. The reason I also provide reload 
functionality is that people in #asterisk-dev expressed a concern that users 
may change nameservers but don't want to restart Asterisk, which is 
understandable. 


Diffs
-

  /branches/12/res/res_pjsip/pjsip_configuration.c 410470 
  /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
  /branches/12/res/res_pjsip/config_global.c 410470 
  /branches/12/res/res_pjsip.c 410470 
  /branches/12/main/dns.c 410470 
  /branches/12/include/asterisk/dns.h 410470 
  /branches/12/configs/pjsip.conf.sample 410470 
  /branches/12/CHANGES 410470 

Diff: https://reviewboard.asterisk.org/r/3343/diff/


Testing
---

Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
and confirmed that the DNS client was disabled. Set to auto (explicitly and by 
default) and confirmed that the system nameservers were used.


Thanks,

Joshua Colp

-- 
_
-- 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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Joshua Colp]

Olle E. Johansson wrote:


On 12 Mar 2014, at 19:53, Joshua Colp mailto:reviewbo...@asterisk.org>> wrote:


This change adds a configuration option for setting nameservers to
be used by the PJSIP DNS client. If this option is not set then the
system nameservers are retrieved and used instead.

This also allows the nameservers to be changed by doing a reload.


Why is this a good thing?


PJLIB-Util (part of pjproject) provides a DNS client which can 
optionally (but is highly suggested) to be used with PJSIP. It provides 
asynchronous DNS, SRV lookups, multiple record support, etc. Right now 
this isn't enabled so we are simply doing A/ record lookups. The 
reason it's not enabled is that explicit nameservers *must* be provided 
to it when enabling it. It will not use the system ones by itself. The 
change up on reviewboard enables it by default using the system 
nameservers it finds, but with the ability to override or completely 
disable it if a user wants. The reason I also provide reload 
functionality is that people in #asterisk-dev expressed a concern that 
users may change nameservers but don't want to restart Asterisk, which 
is understandable.


Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.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

Re: [asterisk-dev] [Code Review] 3343: res_pjsip: Enable DNS support.

[Olle E. Johansson]

On 12 Mar 2014, at 19:53, Joshua Colp  wrote:

> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.


Why is this a good thing?

/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