Hello, I understand your points regarding carriers and interoperability tests, these are of course valid concerns. We also have a certain number of carriers in our customer base, and while we are mostly working with Kamailio, they planned already some years ago projects to update to more modern asterisk versions. So, they already did an upgrade or doing it this year. Some patch we introduced in asterisk in the last months was in fact related to an interoperability certification. You do not need to fully repeat certifications in all cases, sometimes its just a part that needs re-tested.
Regarding the critical system provider, they should also have an update plan. In the end old and not maintained asterisk versions have also seen a fair amount of security vulnerabilities. Especially in this area you should patch your systems. And if you need to do the work anyway regarding tests and upgrades, you could also introduce other changes. But in the end, it boils probably down to a business decision and project prioritization. If there is priority, it will be done faster than five years, if there is no priority, it will be almost never done. 😉 Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com -----Original Message----- From: asterisk-dev <asterisk-dev-boun...@lists.digium.com> On Behalf Of Michal Rybarik Sent: Tuesday, November 22, 2022 11:52 PM To: asterisk-dev@lists.digium.com Subject: Re: [asterisk-dev] chan_sip deprecation Hello, Dňa 22. 11. 2022 o 9:00 Henning Westerholt napÃsal(a): > Hello, > > I am really wondering why people are trying to keep chan_sip alive. No > offence to the past developers, but pjsip is a much better SIP stack > regarding standard compliance and stability compared to the old one. Also, > regarding performance chan_pjsip is better. From an outside view, the > asterisk project gave plenty of time to migrate. If we talk about small PBX with simple functionality, you are probably right that Asterisk project gave plenty time to upgrade, chan_pjsip can handle basic operations for years. But if we talk about advanced and critical systems, I can't agree - changes in chan_pjsip are IMHO still too frequent to even allow starting migration of some systems to it. I have installed different kinds of Asterisk-based systems during last 20 years, from small PBX with few users, larger PBX for critical/emergency services, to operator-grade interconnect/transit gateways. Interconnects between telco operators usually take a *lot* of time to complete and move to production. All possible scenarios must be tested, and if interconnected operator runs several platforms (PSTN, NGN, GSM, VoLTE, IMS), tests may have to be repeated for all platforms, sometimes for several codec combinations too. If some of tests fail, testing is paused and issue must be fixed. If changes could affect something which was already tested, all affected tests must be repeated again. Completing tests on one interconnect (with few issues) can take more than hundred manhours and can last for several months. Replacing SIP stack is like creating brand new interconnect - new hosts must be set up, new (testing) interconnect must be established, all tests done, and only then the production traffic can be switched to the new interconnect and old system turned off. Any further changes, which may affect behavior, needs to be tested before putting to production. In such environment it is much easier to use stable mature component with very rare updates (despite its source code is quite complicated), rather than use new component, which is actively developed and updated frequently. Another story is with PBXes for organizations with critical/emergency services, which started to use Asterisk-based telephony years ago, very carefully and prudently. These systems were continously developed and improved during years, their stability and reliability were proved, more and more users were put on it, several customizations were done. It is not possible to simply replace chan_sip with chan_pjsip in a few hours or days, technically it needs modifications of almost all related (sub)systems developed during decade. It will probably bring lot of smaller or bigger issues and will take lot of time to settle down. And again, it cannot be done in the production environment - organizations won't accept the same/similar issues nowadays which they accepted a decade ago, when system was developed and implemented. I really understand developers' point of view and I'm not telling that we need to stay on chan_sip forever. But my realistic expectation is that fluent migration of our systems (without putting too much pressure on it, which turns positive change to negative emotion) will take maybe five years or so from now. It is not possible to do it before chan_sip is planned to be removed from codebase, and it is also not possible to leave systems for several years without further updates. > Maybe it would be good idea to spend the effort maintaining an old and > deprecated solution towards migration to the new solution. We know that chan_sip is obsolete and generally it's a good idea to replace it with newer implementation, as well as we know that diesel&gas car engines are obsolete and should be replaced with electomobiles (or something else). However, it would be too cruel to force users of diesel&gas engines to migrate to e-car before next October, because their existing cars won't be serviced any longer. > But its open source after all, you can use it as you like of course. God bless all authors and developers of Asterisk for their amazing and valuable work during decades. And God bless Open Source for possibility to keep software alive even when autors decide to orphan it. :-) -- Regards, Michal Rybarik -- _____________________________________________________________________ -- 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 -- _____________________________________________________________________ -- 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
