<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 8:22 AM, Jared Smith <span dir="ltr"><<a href="mailto:jaredsmith@jaredsmith.net" target="_blank">jaredsmith@jaredsmith.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class=""><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 1:04 PM, George Joseph <span dir="ltr"><<a href="mailto:george.joseph@fairview5.com" target="_blank">george.joseph@fairview5.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If we don't static link, we'll never know what's going on.  </blockquote></div><br><br></div></span><div class="gmail_extra">I'm going to push back on this as well.  Short of going the route of static linking, what can we do to improve the current situation with dynamic linking?  Thoughts?  Ideas?  Improved testing?  More robust code?  <br></div></div></blockquote></div><br></div><div class="gmail_extra">I think we're simply facing a fundamental difference in how pjproject expects to be used, versus how we're attempting to use it.<br><br></div><div class="gmail_extra"></div><div class="gmail_extra">Generally, when building pjproject, developers building pjproject must find the right invocation that addresses:<br></div><div class="gmail_extra">(1) Their unique system configuration and its dependencies. Namely, this is telling pjproject which third party packages/libraries it should not use (more on this in a bit as well).<br></div><div class="gmail_extra">(2) Values for #defined parameters that must be set in pjproject for their Asterisk system. This is usually done via either:<br></div><div class="gmail_extra">(2a) A unique site configuration header file<br></div><div class="gmail_extra">(2b) Parameters passed to ./configure directly that determine the value of these directives.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Needless to say, getting these invocations correct the first time is challenging. Often it is not obvious when you get them wrong. For example, failing to set the correct maximum size of your SIP packets in pjproject will simply result in Asterisk rejecting those SIP messages that exceed the max packet size; this has serious implications for anyone wanting to handle SIP packets that contain many ICE candidates.<br><br></div><div class="gmail_extra">This has resulted in an extremely frustrating situation for both Asterisk users and developers. The Asterisk wiki page that details how to configure and build pjproject [1] has been the result, but the complexity of that page highlights just how bad this situation has gotten.<br><br></div><div class="gmail_extra">So why is pjproject such a pain?<br><br></div><div class="gmail_extra">There's probably a number of reasons, and I'm probably forgetting some, but I'd boil the top ones down to the following:<br></div><div class="gmail_extra"><br>* pjproject embeds third party libraries.<br><br>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.<br><br>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.<br><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* pjproject uses defined constants for certain key constraints<br><br></div><div class="gmail_extra">This includes whether or not it supports IPv6, the maximum size of SIP packets, debug assertions, and other items. When pjproject is configured with one set of values, and Asterisk is built against a different set of constraints, very, very, very bad things can happen.<br><br></div><div class="gmail_extra">One work around for this would be to patch pjproject to provide accessors to its defined constants. Asterisk would then use those accessors to get at the values, as opposed to using the constants directly. While that substantially alleviates the issue, the discontinuity between what pjproject views as reality and what Asterisk views isn't uniquely solved by this (we would just stop crashing).<br><br>As an example, consider a case where a package builds pjproject with a maximum SIP packet length of 8192. That means my package is never going to be useful for anyone wanting Asterisk to handle WebRTC SDPs. Likewise, if I've built pjproject with a maximum SIP packet length of 16k, I may have just made it so that my package cannot be used on embedded devices using that distribution of Linux.<br><br></div><div class="gmail_extra">Could this be a configuration driven parameter, as opposed to a defined constant? Maybe, although that isn't pjproject's model. Could a patch be written that makes it do that? Yes, but there are a large number of these types of options, and the burden that this continues to put on the Asterisk developer community is high.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">* pjproject static/shared libraries is confusing for many people<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Is this all user error? Of course. But this happens *a lot*, and it is signals that there is a problem with the environment that we're expecting people to operate under.<br><br><br></div><div class="gmail_extra">Can all of the above issues be alleviated in some fashion via various technical changes? I'd hazard a guess and say "yes". However, I think that even if we alleviate them, we're going to still be left with a situation where the most important functionality in Asterisk - its SIP stack - is more challenging to get configured and set up than what users feel it should be. That's a bad situation for users. I know the packagers feel that having anything embedded or statically linked is worse for users; unfortunately, after witnessing where we're at after nearly three years with the current model, I disagree with that feeling.<br></div><div class="gmail_extra"><br>I think a number of developers in the Asterisk project are frustrated by this situation. There has been a lot of time and energy invested into trying to make the current model work, and we still see a lot of users frustrated by the current requirements we're levying on them. Continuing to throw more development time at a problem to satisfy a small group of people who categorically refuse to brook any compromise is a difficult proposition for me.<br><br>I'll go so far as to say that in my time on the Asterisk project, I personally feel that the single worst technical decision I've made was in making it so that the only way to use pjproject was via shared object libraries. The pain to users, and the impact this has had on adoption of the PJSIP stack in Asterisk, isn't something I can even begin to calculate.<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br>[1] <a href="https://wiki.asterisk.org/wiki/display/AST/Building+and+Installing+pjproject">https://wiki.asterisk.org/wiki/display/AST/Building+and+Installing+pjproject</a><br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Director of Technology<br></div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div></div>
</div></div>