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

Michael L. Young myoung at acsacc.com
Wed Jan 20 16:06:19 CST 2016


> From: "Jeffrey Ollie" <jeff at ocjtech.us>
> Sent: Wednesday, January 20, 2016 3:28:44 PM

> On Wed, Jan 20, 2016 at 11:04 AM, Tzafrir Cohen <
> tzafrir.cohen at xorcom.com > wrote:

> > Hang on. This is RHEL. A stable platform. Why can't they just use
> 
> > pjproject packages and be done with it?
> 

> It's been my experience that a large number of Asterisk users compile
> almost everything from source because that's the way they've always
> done things, partly because that's just the way that they like to do
> things, and partly because that's the way they had to do it back
> when you couldn't get Asterisk packages and the only way to get it
> was to compile it yourself.

> --

> Jeff Ollie

I have to agree here with Jeff. 

Could most of the issues that are being encountered have to do with users upgrading their version of Asterisk on the same machine where they now have a mix of installed libraries instead of building a new system from scratch? Could that be part of the problem? 

My gut feeling is that users upgrading from Asterisk 11 to 13 are not reading the wiki. They are trusting that they already know how to install and setup Asterisk based on their prior experience and do not realize that PJSIP needs to be handled differently between those versions. I know the comment on the wiki that there is an Asterisk compatible version of pjproject available on github would make me think that I should be installing that rather than using the one provided by my Linux distro of choice because it would cause me less problems. At least that is what my first thought would be. Especially when I see later on in the wiki is describing downloading a newer version of the pjproject than what my distro provides. Again, someone looking at this page briefly and in a hurry, if they are looking at all, could miss a lot of the details that are right there if they would just pay attention to it. 

We used to compile Asterisk because that is what was always done and how we were always shown how to get Asterisk installed. Also, we could deal with the occasional hiccups from using the latest and greatest when it came to libraries and applications. There were no packages for Asterisk and in order to have latest and greatest with all those bug fixes in them, it was best to get the latest code and compile it. 

Now, times have changed. We need to use packages and choose to use stable packages wherever it is possible. As our company has grown, security standards and stability now take priority over the easiness that comes with downloading and compiling. We are no longer allowed to have code or any development tools on our production servers. 

The steps that the project took over the past few years to make Asterisk easier for those of us who now are required to create / use the packages for our production servers was great and it helped to ease our burden. 

Perhaps it is just a culture change within the community in regards to how we are accustomed to getting Asterisk on our systems and this is part of the pains associated with this shift in what was once considered the "norm". 

Anyways, just some insight from a different perspective on this issue. 

I completely understand the problems that Matt outlines. The issue, from what I understand, has to do with user experience and the ability to support the user. We have two different projects with two different approaches. It is too late now but I believe one of the main concerns with going with a third-party SIP stack during those discussions was whether or not we could work with the upstream whenever a problem arised. It would appear that this goal is not easily attainable with pjproject based on what Matt just outlined in his prior email if I understood it correctly. If the only way to keep Asterisk moving forward without wasting time and effort on the same problem over and over again is to bring it back in, then I think the decision to be made is very easy. The rest of us will have to find a way to deal with it when it comes to packaging. 

Just my thoughts that I have been having for the past few days while following these discussions. I hope it helps to give some more insight from the "front lines" perspective while trying to make a decision on this. 

Michael 

(el guero) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160120/8ca6f865/attachment-0001.html>


More information about the asterisk-dev mailing list