[asterisk-dev] Proposal to bring pjproject back into the fold

[George Joseph]

On Tue, Jan 19, 2016 at 7:25 AM, Joshua Colp <jcolp at digium.com> wrote:

> George Joseph wrote:
>
> <snip>
>
>
>>
>>     There is the middle ground which is keep the ability to link against
>>     a shared system library if present but also bundle a pjproject and
>>     use it if the system library is not present (or you force the
>>     bundled version).
>>
>>
>> I was also thinking we could statically link against the
>> system-installed version but we're still back to the same problem where
>> we have no clue at runtime what we're running against.​
>>
>
> That's a decision with consequences that others have to make (such as the
> distros).


​Yep.  See my response to Matt.​


>
>
>
>>
>>         pjproject was deeply embedded in 11 and I don't think that was
>>         right but
>>         I think we went too far in 13 by taking the hands-off approach.
>>         Maybe
>>         at the start of 13 it was ok, but we've since put chan_sip into
>>         "extended" support so we're pushing chan_pjsip as the supported
>>         stack,
>>         instead of it just being optional.  Not to mention that chan_sip
>>         needs
>>         res_rtp_asterisk which is also dependent on pjproject.  Can you
>> see
>>         where I'm going? :)
>>
>>
>>     In the current shared library method it is not a hard dependency.
>>
>>
>> Strictly true but ​if you want ICE, TURN or STUN support, you need
>> pjproject, no?
>>
>
> Yes, but in the grand scheme of things the part of the user base using
> those features is much smaller than the rest. If they get it as a result of
> pulling pjproject in more then *shrug* it's fine. I just don't consider it
> a reason for doing this. ^_^
>
> ​Agreed.  I'd never propose this on this basis only.  It's just one more
thing to add to the mix and there are going to be more things added I'm
sure.​


>
>
>>
>>         I propose that we bring pjproject into a new 'third-party'
>>         directory and
>>         statically link our res_pjsip* modules to it.  We should NOT
>>         check it
>>         into the Asterisk repository however.  Instead we should use
>> scripts
>>         like get_mp3_source to get a specific pjproject version and a
>>         'patches'
>>         directory that IS checked in that has things we've discovered we
>>         need.
>>         The patches should always be proposed upstream.
>>
>>         It's a lot of work but I'm willing to dig in and I'll bet I
>>         could get a
>>         few volunteers to help.
>>
>>
>>      From a technical perspective you can not statically link each
>>     module to PJSIP, each module will end up with its own isolated
>>     running copy. You need to statically link it into one module
>>     (res_pjsip, or res_pjproject for example) and have it export all of
>>     the symbols to everything else. Additionally because all the symbols
>>     aren't actually being used the linker also likes to remove them
>>     unless you do magic to force them to be present regardless. This is
>>     how the PJSIP support was originally developed before shared library
>>     support was added to pjproject. If you go back in time almost
>>     everything needed to make it work in a bundled configuration is
>>     there already.
>>
>>
>> ​I was nosing around 11 last night ​and realized that the plumbing is
>> there.  That's why I updated my level of effort. :)
>>
>
> Not quite, 11 is easy because it's all in one module (res_rtp_asterisk).
> 13 is hard because multiple modules use it, so you have to do what I said.
> I spent a few days making it work so we could write functionality before it
> was in a shared library form. "WHY ARE THESE SYMBOLS NOT IN HERE?!?" "Oh,
> the linker decided they weren't used and took them out. Great."


​Understood.​


>
> --
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160119/e1aa7b04/attachment.html>