On 14 Mar 2014, at 16:57, Paul Belanger <[email protected]> wrote:
> On Fri, Mar 14, 2014 at 10:29 AM, Olle E. Johansson <[email protected]> wrote: >> >> On 14 Mar 2014, at 15:22, Sean Bright <[email protected]> wrote: >> >>> On 3/14/2014 10:02 AM, Olle E. Johansson wrote: >>>>> It would mean continuing to maintain Asterisk's pjproject fork until >>>>> those changes were (hopefully) accepted upstream, released, and then >>>>> waiting for the rpm/deb packages to catch up. Not to mention that >>>>> someone would actually have to _do_ all of this work. Could all >>>>> volunteers please raise their hands? ;-) >>>> >>>> If this is how we are going to manage our product then I'm getting really >>>> worried. Are we controlling our own software? >>> >>> I'm not sure why you are getting worried. If you would like to improve the >>> DNS resolver within Asterisk are you not free to do so? >> >> And I'm doing it. >> >> My problem is when I get arguments like "it's there in PJIP so we have to >> use it" or "we can't do anything because of PJSIP". >> >> PJSIP doesn't do happy eyeballs, doesn't do SIP outbound and misses a lot of >> features that we do need. If we are locked down waiting for them and can not >> control our own fate as a product, we are in really bad shape. >> >> I am not saying they are not doing a good job in PJSIP, but if I was a >> product manager for Asterisk I would not like having so little control of >> one of the most important modules. >> > I cannot remember if we talked about this at astridevcon or not, but > by using an external library you are some what committed to using > there feature set. Which, is fine IMO. However, as new features are > needed / added, we'd ideally work with upstream to get them merged up. > I'm pretty happy we finally got all the patches to pjproject merged by > teluu, but some what concerned about the troubles other people have > had getting code merged (I think ajprojects). I'm not sure if Digium > had to get some support agreement or not but at the end of the day, we > are dependent on teluu's workflow process. Which means we are loosing the competitive edge as well as our control. Which was something I was worried about all along. Anyway, I am sure we can speak with the PJSIP guys about this and fix it in the right way. We still need to have as a goal to have a good and clean architecture and be a good citizen in the Unix/Linux servers we run. The PJSIP stack was written primarily for phones, not servers, which from time to time shows. This is one area where the architecture is bad for a server. /O -- _____________________________________________________________________ -- 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
