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
