[asterisk-dev] Proposal to bring pjproject back into the fold
Tzafrir Cohen
tzafrir.cohen at xorcom.com
Wed Jan 20 11:04:25 CST 2016
On Wed, Jan 20, 2016 at 09:49:32AM -0600, Matthew Jordan wrote:
> On Wed, Jan 20, 2016 at 8:22 AM, Jared Smith <jaredsmith at jaredsmith.net>
> So why is pjproject such a pain?
>
> There's probably a number of reasons, and I'm probably forgetting some, but
> I'd boil the top ones down to the following:
>
> * pjproject embeds third party libraries.
>
> Some of those third party libraries are also libraries that Asterisk can
> use; if Asterisk needs to use them, you have to tell pjproject to not use
> its embedded version. While it is easy to say that pjproject should "just
> not do that", that misses the original - and still one of the most common -
> use cases of pjproject; namely, as an embedded systems library. For people
> building SIP devices on embedded platforms, having embedded versions of
> GSM, SRTP, and other useful libraries is actually advantageous. Packages
> are not usually available for, say, VxWorks, and if I know pjproject can be
> built using my esoteric toolchain, I don't have to try and make libsrtp
> build as well with it.
>
> As a result, pjproject is highly unlikely to ever remove their embedding of
> third party libraries, despite our attempts at convincing them to do that.
> They serve *more* than just the Asterisk project, and our needs are not
> always going to match 100% with theirs.
>
> The implications of that are that we're going to need to work around and/or
> deal with the third party libraries they embed in some fashion.
I'm not sure what your exact issue is here.
Is there any specific library that pjproject currently embeds that can't
be trivially disabled? Do you think there is an issue with pjproject not
defaulting enough to using system libraries where possible?
> * pjproject static/shared libraries is confusing for many people
>
> It is not uncommon for people to build static libraries of pjproject the
> first time around (missing the instructions to not do that), install them,
> and run Asterisk. Asterisk then will crash or do something terrible. They
> will then attempt to install the shared object libraries, not removing the
> static libraries. Asterisk will still run, and now crash in a different
> fashion. They will then attempt to remove the static libraries, and now
> Asterisk will complain that it can't find pjproject because you're using
> RHEL and your pkg-config path isn't set up correctly.
Hang on. This is RHEL. A stable platform. Why can't they just use
pjproject packages and be done with it?
>
> [1]
> https://wiki.asterisk.org/wiki/display/AST/Building+and+Installing+pjproject
Looking there I see: --disable-sound, --disable-resample: let Asterisk
perform sound / resample. Is there anything wrong with having those
enabled? Because for a general-purpose version of pjproject I do need
those enabled. Likewise --disable-video. Yes, I see the extra
dependencies, and I tried to do something about them (remove unused
libraries).
Off-topic: is there any point in providing the pjsua (the terminal-based
example client) in a separate binary package from the pjproject source
package? Is it useful enough for testing?
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com
More information about the asterisk-dev
mailing list