On Fri, Aug 8, 2014 at 1:54 PM, Matthew Jordan <[email protected]> wrote: > Hey everyone! > > As you may have noticed, we've branched Asterisk 13 and will soon be > releasing the first beta release. Asterisk 13 is the next Long Term > Support (LTS) release of Asterisk, building heavily on the new > architecture and features developed in Asterisk 12. One of those new > features is, of course, the PJSIP stack in Asterisk. Today, we decided > to make a big commitment to the ongoing development of the PJSIP stack > in Asterisk by marking chan_sip as Extended support. > > What does being in Extended support mean? > > First, Extended support modules are still supported in Asterisk - just > by the community as a whole, and not by Digium specifically. A large > number of modules are in Extended support, and are actively supported > by members of the Asterisk Developer Community. When security issues > are found in Extended support modules, all developers - including > those at Digium - focus on fixing them. When architectural changes > affect Extended support modules, all developers - including those at > Digium - do their best to maintain Extended support modules. Some > developers at Digium also actively participate in maintaining and > developing Extended support modules, albeit usually in their free > time. However, such modules are not focused on by Digium developers, > and issues reported against Extended support modules are generally > handled by the community. > > That being said, chan_sip is Core supported in Asterisk 1.8, Asterisk > 11, and Asterisk 12. Bugs reported against chan_sip in versions of > Asterisk derived from those branches will continue to be triaged and > handled by Digium as well as by the overall developer community. All > fixes for bugs found in chan_sip will continue to be merged into all > supported branches. While chan_sip may be in Extended support in > Asterisk 13, this does not change the support obligation that Digium > has with chan_sip in those branches where it is marked as Core > supported. As such, the bug-fix policy for chan_sip is the same for > Asterisk 1.8, 11, and 12 while those branches remain under active > bug-fix maintenance. > > However, it does mean that when Asterisk 11 enters into security fix > only mode in 2016 [1], developers at Digium will no longer focus on > fixing bugs in chan_sip. > > So why mark chan_sip as Extended support now? > > One of the major motivating factors for replacing chan_sip was the > support burden we faced with that channel driver. Due to its > architecture (or lack thereof), changes in chan_sip often have > unforeseen negative repercussions. Fixing a bug in chan_sip often > creates a new one. Adding a new feature is difficult, particularly if > that feature interacts with the SIP protocol at a low level. And, > while the addition of over 100 unit and functional tests has helped > tremendously, chan_sip does its best to resist change. I went into > more detail on the motivation behind moving away from chan_sip in a No > Jitter blog post [3]; without rehashing the details here, it suffices > to say that despite the best efforts of many smart, talented > developers, chan_sip sucks a lot of time and energy from those who try > to maintain it. > > The Asterisk team at Digium consists of approximately ten developers > and a community support manager (Hi Rusty!). We always attempt to > focus our development efforts on the parts of Asterisk that give the > most benefit for the entire Asterisk community. In Asterisk 12, this > involved writing not just a new SIP stack, but also substantial > development in the Asterisk core and its interfaces. Focussing on > improving the fundamental architecture of Asterisk has great long term > benefits for the community, but it does come at a cost. To make these > kinds of architectural improvements requires a large investment of > time and energy. While we were able to do this in Asterisk 12, we do > not feel we can continue to make these kinds of investments while > indefinitely supporting chan_sip at the same level as the PJSIP stack. > There's no question that we will continue to support chan_sip for the > next two years, but marking chan_sip as Extended support now provides > some timeframe under which we can plan to devote more resources to > making bigger and better changes in Asterisk. > > So, does this mean that chan_pjsip has the same level of functionality > as chan_sip? > > No. There are things that chan_sip can do that chan_pjsip cannot do > currently (CCSS, for example). There may always be some features in > chan_sip that are not replicated in chan_pjsip - and that's okay. One > of the great things about open source software is that if a feature is > truly needed, someone will write a patch for it! > > So should I plan to move everything to chan_pjsip now? > > We have gotten some great feedback on chan_pjsip (thanks SchmoozeCom > and FreePBX!), and are actively fixing bugs, addressing > interoperability concerns, and adding new features. We feel that > chan_pjsip is in great shape and will work for many deployments and > scenarios. At the same time, it has not been deployed as widely as > chan_sip, and so there may be interoperability problems that will > arise. We'll do our best to respond to those issues and get them > fixed. > > Regardless of any criticism that may be levied against chan_sip, it > has one obvious advantage: it has been around a long time and a lot of > very talented developers have put countless hours into it. As a > result, it has accumulated years of interoperability patches and > fixes, which has made it able to work with a large variety of > equipment, phones, ITSPs, and other SIP flavored things that I can't > even predict. The benefit of having so much energy devoted to it > cannot be underestimated. This is why we worked hard to make sure that > both chan_sip and chan_pjsip can operate together. If, while using > chan_pjsip, an interoperability bug is discovered, a user of Asterisk > has the option to fall back to chan_sip while the developers work on a > fix. The support status of chan_sip is independent of this scenario > and is merely a reflection of where we, as developers at Digium who > spend our careers working on Asterisk, want to focus our effort and > time. > > Hopefully, this e-mail provides some transparency into why we made > this decision. Asterisk 13 is the first LTS release built on the > architecture and PJSIP stack introduced in Asterisk 12, and as such, > we are focused on making sure that users of Asterisk have the best > experience possible. We would not have gotten here without the hard > work of everyone in the community: so as always, thank you for your > continued support of the Asterisk project! > *grabs popcorn and prepares for action*
Joking aside, I don't see an issue with this. Even though I have done zero testing with chan_pjsip at the moment, I am happy to see it being promoted. Obviously there is going to be some bumps in the road however I'd rather see development efforts focused on chan_pjsip then split with chan_sip. If you are a digium developer, find me at Astricon, there will be a beer in it for you. -- Paul Belanger | PolyBeacon, Inc. Jabber: [email protected] | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _____________________________________________________________________ -- 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
