[asterisk-dev] chan_sip deprecation

Michal Rybarik michal at rybarik.sk
Tue Nov 22 16:52:25 CST 2022


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




More information about the asterisk-dev mailing list