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

[Matthew Jordan]

On Fri, Mar 14, 2014 at 9:29 AM, Olle E. Johansson <oej at edvina.net> wrote:
>
> On 14 Mar 2014, at 15:22, Sean Bright <sean.bright at gmail.com> 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