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

George Joseph george.joseph at fairview5.com
Mon Jan 18 21:27:35 CST 2016

On Mon, Jan 18, 2016 at 7:12 PM, George Joseph <george.joseph at fairview5.com>

> 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.
> 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? :)
> 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.
​Actually, it's not a lot of work.  I'll be done Wednesday. :)​

> Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160118/85f51bdf/attachment.html>

More information about the asterisk-dev mailing list