Chan_sip vs chan_pjsip performance

Dear Community,

Im setting up a Asterisk 17.3.0 and I was wondering if there is some “good” (in terms of reliability) statistics about the performance of these two channel types, all i know is that this was a good topic in certain Astricon “meetings” and some comparative images about CPS (But im not sure about it)

I will apretiate any information related to this

1 Like

I’ll let more ‘learned’ be definitive but I would suspect that in a typical call SIP only accounts for a handful of packets and RTP accounts for bazillions so the selection of chan_sip vs chan_pjsip should be made on the common wisdom of ‘unless you have a reason why not, you should be using PJSIP.’

1 Like

Thanks for your recommendation @sedwards , im still a newbie in this environment, thats why i don’t have a common wisdom ‘yet’, and we use chan_sip in another asterisk builds, thats why im wondering what would be the best.

I hope that this clarifies why i posted this topic :sweat_smile:

I confess I’m still running chan_sip everywhere. My clients are running systems that I developed before PJSIP and every time I ask they reply “Explain why I should spend sacks of cash and risk disruption to my business for no perceptible benefit? If it ain’t broke, don’t fix it.”

So until there’s a security flaw that’s a ‘business killer,’ they’re not interested.

So, do as I say, not as I do :smiley:

The object concept implemented by PJSIP add more flexibility compared with the static configuration of chan_sip.

Chan_SIP has been dead for quite some time. It is no longer maintained by Digium or the Asterisk project. It receives no new development, it is only supported by the Community (so if there is a bug, someone not Digium needs to fix it and submit it). It is also on the chopping block. It can (could) be removed from Asterisk fully as early as 2023. As it stands right now from 17 and all future releases Chan_SIP has to be compiled when you compile Asterisk in order to use it.

There are plenty of reasons to get them off it.

1 Like

All valid points, just not compelling.

Imagine if somebody tried to sell you ‘Pandemic Insurance’ last November. What would your significant other say if you said you spent the vacation money on insurance for something no living person has any recollection of? Or, assuming you live in the US, ‘Ebola Insurance?’

Until they need to add functionality that cannot be implemented in their current code base or until there are documented, in the wild exploits, it just won’t happen.

1 Like

So you said you setup Asterisk 17, did you compile it with Chan_SIP? Something you’re going to need to do each time you update Asterisk from this point forward.

And what would be compelling? Because PJSIP out performs Chan_SIP in numerous ways on top of the fact Chan_SIP is the walking dead. So what is the actual thing that would compel this move?

You are conflating posts. I never mentioned A17.

Already answered.

You’re right, I did. My apologies. However at this point you need to start learning PJSIP if you haven’t. 2023 isn’t that far away when it comes to this and it is going to require some overhauling of the system. Not just converting your Chan_SIP peers to Chan_PJSIP but you need to modify your dialplan and other functions to call on the new PJSIP functions/features.

This, we agree on :slight_smile:

Once you understand the relationship between pjsip sections is easy to use and you will love it and you wont want to go back to chan_sip. At the very beginning I was afraid to the switch because chan_sip is very stable, but then pjsip was quite new, but know PJSIP is reliable and robust and with more features a and adding more flexibilty than chan_sip

Chan_SIP, because Gareth codes his patches for USECALLMANAGER (http://usecallmanager.nz/document-overview.html) for chan_sip and not PJSIP

This only applies to people using Cisco phones. So far that hasn’t been mentioned here. It’s not a driving factor for many users.

It also cannot be stressed enough that Chan_SIP is on its way out. The Asterisk developers have been pushing this point for a very long time. Again, the OP installed Asterisk 17 which would require Chan_SIP to be compiled at install as an additional option. It’s no longer default installed with Asterisk 17.

So that means unless a user has specifically done this they DO NOT have Chan_SIP readily available for them on an Asterisk 17 install. Unless third party vendors like Gareth get off their ass soon as start doing something to address this then either A) they won’t have to worry about it because no one will be using it from that point forward or B) They’ll be forcing people to stick on a version of Asterisk (16 or lower) that will be unsupported and receive no updates because their lifespan has ended.

It’s going to be like Asterisk 12/13 a few years back where numerous vendors gave up the ghost because they didn’t want to include new features like Chan_PJSIP in their software. This is how A2Billing died.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.