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

[George Joseph]

On Tue, Jan 19, 2016 at 6:06 AM, Matthew Jordan <mjordan at digium.com> wrote:

>
> On Tue, Jan 19, 2016 at 6:04 AM, Joshua Colp <jcolp at digium.com> wrote:
>
>> George Joseph wrote:
>>
>>> I'm VERY frustrated with pjproject right now.  Not the software itself
>>> (well maybe a little) but the fact that troubleshooting is a nightmare
>>> because we can't control what version of pjproject was installed along
>>> with Asterisk and we can't control what options it was compiled with.
>>> This leads to issue where we're getting great debugging from Asterisk
>>> but nothing at all from pjproject because the user installed from their
>>> distro and it has no debugging info.  So now we have to walk them though
>>> getting pjproject from source, etc, etc.  This can also cause issues
>>> should Teluu change an API or some behavior that we're not prepared for
>>> and the user just does a 'yum update pjproject' and Asterisk dies.  Then
>>> there's the issue where even though the verison is the same, the
>>> compiled-in options differ, some of them quite fatally.  That unleashes
>>> a whole other mess.
>>>
>>
>> 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'd certainly still like a packaged pjproject to take precedence if
> available. This allows package maintainers to meet the guidelines of their
> distros, and eases their burden.
>

​I understand the packaging issue and I'd like to hear from packagers like
Jared Smith.    We could simply require a specific version of Asterisk to
be statically linked to a specific version of pjproject and let the
packaging process insure it's there.  For rpms, a BuildRequires would do
that.  There's be no runtime dependency after that.


>
>
>>
>> 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.
>>
>>
>>> 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.
>>
>
> Would we automatically download and link pjproject when someone runs
> 'make', or would it require some different make target?
>

​The more I think about it, maybe we don't need to bundle.  Maybe it's just
enforcing a specific version to be available for static linking.​


>
> --
> Matthew Jordan
> Digium, Inc. | Director of Technology
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160119/b2b778a2/attachment.html>