[asterisk-dev] chan_sip deprecation

[Olle E. Johansson]

> On 22 Nov 2022, at 09:13, Jon Bonilla (Manwe) <manwe at aholab.ehu.es> wrote:
> 
> El Tue, 22 Nov 2022 08:00:48 +0000
> Henning Westerholt <hw at gilawa.com> escribió:
> 
>> 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.
>> 
> 
> Not defending here keeping chan_sip, it will be removed and chan_pjsip will
> need to be adopted. But just from my point of view as asterisk based solution
> developer:
> 
> We know chan_sip. We know what works and what fails. And we know the
> workarounds for what fails. Having hundreds of asterisk servers working 24/7
> during  the last 7 years I had 0 crashes using chan_sip (don't saying here that
> chan_pjsip would have been different).
Same here. But I see no reason to continue working with the code in chan_sip.
I know all the issues it has, the horrors in the code and how hard it became to fix anything.
The single-thread socket listener is causing real bad issues when you hit it 
with heavy traffic.

It’s time to move on and leave chan_sip. 

For me, the question is if it’s time to move to chan_pjsip
or somewhere else entirely. I don’t know yet, but chan_pjsip can’t really
solve the problem with the ISDN-like Asterisk core where all my SIP/RTP calls have to 
go through. At this time, the multiprotocol architecture that was the reason
for using Asterisk, and why Asterisk was in the spotlight,
is causing more and more issues that I have to handle
in Kamailio.

/O
> 
> No need of new features here as I use kamailio for some stuff like path,
> paralel forking, websocket handling and all kind of stuff. Just want chan_* to
> send/receive calls fast. 
> 
> chan_pjsip probably hasn't routed yet 1% of the calls chan_sip routed in all
> history. 
> 
> So, In my case it's more confortable to keep chan_sip as I don't need anything
> else and I have 0 issues with it. Maybe others are in the same position.
> 
> 
> But IMHO chan_sip must be removed. I understand what the development is and
> it's a PITA to keep old code and even keeping it unmantained is a pain. When
> the time comes I'll move to chan_pjsip and I won't complain. Grateful to the
> asterisk devs that provide such a great solution.
> 
> cheers,
> 
> Jon
> 
> 
> 
> -- 
> PekePBX, the multitenant PBX solution
> https://pekepbx.com
> 
> -- 
> _____________________________________________________________________
> -- 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