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

[George Joseph]

On Tue, Jan 19, 2016 at 5: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 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.​


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


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


>
>
> --
> 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/d87000e9/attachment.html>