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

Mon Aug 14 20:53:31 CDT 2017

On Tue, Aug 15, 2017 at 2:07 AM, George Joseph <gjoseph at digium.com> wrote:

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

I was referring to 11 where it was within the source code itself - I know
this isn't the same - distro creators can disable it etc etc, can build
things with pjsip how they want whereas they couldnt before...

I'm more playing devils advocate - I personally don't have an issue with it
myself. Just replies had been sparse and I think the above rant is
important to be seen in public :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170815/c33ad674/attachment.html>