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

[Joshua Colp]

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

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

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

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