[asterisk-dev] Making pjproject_bundled the default in Asterisk 15

George Joseph gjoseph at digium.com
Mon Aug 14 20:07:08 CDT 2017


On Mon, Aug 14, 2017 at 1:04 PM, Dan Jenkins <dan.jenkins88 at gmail.com>
wrote:

>
>
> On Tue, Aug 8, 2017 at 10:44 PM, George Joseph <gjoseph at digium.com> wrote:
>
>>
>>
>> On Tue, Aug 8, 2017 at 1:15 PM, George Joseph <gjoseph at digium.com> wrote:
>>
>>> The option to use the bundled version of pjproject has been available
>>> since January 2016 and is the only "supported" method of using pjproject
>>> now.  It's also the only effective way to troubleshoot since things like
>>> DONT_OPTIMIZE and MALLOC_DEBUG are passed down the the bundled build.
>>>
>>> You can still disable it of course with '--without-pjproject-bundled'.
>>>
>>> There have been comments about needing internet access to build but you
>>> can download the tarball and checksum yourself and place them in a known,
>>> static, location, then use the '--with-externals-cache' option to tell
>>> configure where it is.  Same for the precompiled codecs and the DPMA.
>>>
>>> You can also use the PJPROJECT_URL environment variable to change the
>>> downlaod URL to a file:/// (or any) URL that points to the directory where
>>> the tarball and checksum are located.
>>>
>>
>> After some discussion I've added the following...
>>
>> To make building without an internet connection easier, a new ./configure
>> option '--with-download-cache' was added that sets the cache for externals
>> (like pjproject, the codecs and the DPMA), AND the sounds files. It can
>> also be specified as an environment variable named "AST_DOWNLOAD_CACHE".
>> The existing '--with-sounds-cache' option / SOUNDS_CACHE_DIR env variable
>> and '--with-externals-cache' option / EXTERNALS_CACHE_DIR env variable
>> remain and if specified, will override '--with-downloads-cache'.
>>
>>
>>
>>
>>>
>>> Thoughts?
>>>
>>> --
>>> George Joseph
>>> Digium, Inc. | Software Developer
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>>> Check us out at: www.digium.com & www.asterisk.org
>>>
>>>
>>
>>
>> --
>> George Joseph
>> Digium, Inc. | Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: www.digium.com & www.asterisk.org
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
> Is this not the problem that people didn't like about PJSIP back at the
> very beginning? I know the code isn't inside the Asterisk source code etc.
> But should we be forcing people by default to use bundled?
>

Yes.  But let me tell you why. :)

It's already bad enough when folks report crashes with no backtraces or
backtraces without DONT_OPTIMIZE and BETTER_BACKTRACES, with 10000 line
dialplans and 2mb log files and say "yeah it only happens every 1000 calls
or so and we can't reproduce it".  Now throw in an external pjproject, at
god knows what version, with god knows what compile options, and
symbols???, good luck.   It's even worse if they're using a packaged
pjproject because then even the reporter has no idea what compile options
were used or what packager-specific patches were applied and if they didn't
install the symbols, backtraces will be useless.   It can take us days or
even _weeks_ to get the reporter to the right configuration for a usable
backtrace.   We just can't support that variability any more.   With
bundled, we know EXACTLY what they've got and how its configured.   *That*
we can support.  Also consider that many of the issues with pjproject are
actually memory corruption issues that probably aren't even caused by
pjproject.  With the bundled version, when you specify MALLOC_DEBUG in the
asterisk compile options, we turn it on for pjproject as well.  That's
something that CAN'T be done with external pjproject, even if you compile
and build it yourself, because it's asterisk-specific code that gets
compiled into the pjproject memory management stuff.

Given all that, and the fact that bundled is what we test and we patch
bundled and send those patches upstream, I don't think it's unreasonable to
make it the default in 15/master and say "We can't help you troubleshoot
beyond basics if you aren't using the bundled version of pjproject".  Now
we can't be assholes about it but we should be firm and if they have an
issue with bundled, *at least tell us why so we can fix it*.  I can also
understand packagers (or pbx distros) creating matching asterisk and
pjproject packages and that's fine.  Or would be if they actually took
responsibility for providing support, but they rarely do.

If someone doesn't want to use it, fine.  They can specify
--without-pjproject-bundled on the configure command line.  They just can't
expect support from us.  If I had my way, I'd add a field to the Jira new
issue dialog that makes you confirm that you're using bundled if any
component selected is pjsip related and another one that make you confirm
that, in the event of a crash, you've compiled asterisk with DONT_OPTIMIZE,
BETTER_BACKTRACES and MALLOC_DEBUG and that you've generated backtraces
with ast_coredumper.   Don't check the boxes and we don't even look at the
issue.

Sorry for the rant but I've had a few of these just in the past few weeks.
:)


> I personally don't have an issue with it (As I use bundled all the time
> now) - just thinking back to what people had an issue with however many
> years ago
>

Are you thinking back to issues with bundled or pjproject in general?   Or
even back to Asterisk 11 where we had a version of pjproject checked into
the source tree that we used for ICE, etc.?  I do remember issues from 13
but before bundled where we got complaints that we weren't supporting the
"latest" pjproject version but that should be a non-issue now.


> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | 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/20170814/5ae59b8b/attachment-0001.html>


More information about the asterisk-dev mailing list