PJSIP vs CHAN_SIP feature and functional parity

General Help
1

Sorry for the late response - I missed this, but it’s important enough to follow up on.

The problem with PJSIP is that IPPBXs and phones/trunks no longer live in their own little world in modern networks. Things like software-defined networking, deep packet inspection, statistical behavioral analysis (Cisco StealthWatch and competitors), etc. are becoming necessary facts of life. These rely on adherence to commonly-accepted standards. We can debate the political and industry problems involved with which standards are more universally embraced and which aren’t, but that’s about as useful as arguing with your houseplants - things are what they are. For all of its nasty code foibles, CHAN_SIP works very well with the “rest of the world.” CHAN_PJSIP has been, in our experience, a complete trash fire in what we consider to be a reasonably secure network infrastructure. We tried it, it failed spectacularly, and I haven’t had a few days or weeks to spend inspecting packet captures and log dumps to figure out why. “Just turn off your security systems” hasn’t been an acceptable response for the last 15 years and while I’m hesitant to make unequivocal predictions of the future… I’m going to go ahead and make one here and say that isn’t going to change. I really don’t care which code base is used as long as it plays nicely with others. PJSIP might be a better collection of standards (I’m the worst person to make that call) and CHAN_PJSIP may be a better code base (I have no idea), but it either works or it doesn’t. So far, for us, it doesn’t.

2

I spend a good chunk of my work week looking at SIP packets, and have for years. While I expect there might be something, I can’t think of a single thing that differentiates a chan_sip packet from a pjsip packet.

3

Thanks for your concerns. However, In the freepbx world we are going to continue to back pjsip 100%. I see this being more the case now with the acquisition. We need to continue on the path digium has set. Not derail it into the past. Chan_sip as it stands now works and will continue to work for the foreseeable future. The community is free to come along and update it at any time however development will continue with pjsip.

4

I can understand why this is (especially if CHAN_SIP is the code mess it’s reputed to be), but it might be worth considering having some configuration options in CHAN_PJSIP that limit some of its extended functionality in the name of keeping peace with other parts of the network. More sophisticated network management and security are going to be pushed down into the smaller enterprises where FreePBX typically makes its home - as a matter of survival if nothing else - and the issues I’m describing will likely become more prevalent. Unfortunately, some of the larger security players like Cisco and Microsoft will probably consider incompatibilities with PJSIP as a feature rather than a bug if it pushes customers into their competing options.

5

Erik

I honestly have no clue what you are talking about. We use pjsip internally and don’t have to “turn off security features”. Pjsip has been in asterisk for four years now and this is the first time I’ve ever heard of having to turn off security features (no idea what that means)

6

I’m not sure why either. As mentioned, we couldn’t make it work. At the time, we were not able to devote many resources to the issue and took the easy way out. We could troubleshoot it, but it would probably be expensive. My understanding is that, from an RFC-compliance standpoint, PJSIP is a superset of the more traditional SIP implementations - so even if we found and eliminated any existing issues we might wind up playing “whack-a-mole” with compatibility problems for the foreseeable future, which does not excite me. We’ll try to find some resources to nail this down further - my preference is to make things easy for everyone, but we can only afford so much…

7

Your understanding is wrong. PJSIP is SIP. PJSIP is the name of an implementation of SIP. As is SOFIA. Would you call SOFIA a superset of SIP. No. Same as Chan_sip isn’t either. Chan_sip, PJSIP and SOFIA are all implementations of the SIP RFC.

8

I find most firewall issues don’t care about SIP vs PJSIP. What they do care about are VPN’s and setting a VPN tends to solve a lot of our firewall issues.

1 Like
9

@ecarlseen So you’re having/had issues with deploying Chan_PJSIP trunks and or extensions? What are/where the actual issues? Because just saying “It doesn’t work and it’s a trash fire” without actually saying why you think that is just a waste of time to discuss.

Since you’re talking about packet inspection and firewalls then let us cover some things here. If you have a PBX running Chan_SIP on the standard ports OR Chan_PJSIP on standard ports, guess what? The setup in your firewall IS NO DIFFERENT. You still have to setup NAT/forwarding rules for port 5060 for signalling and ports 10000-20000 for RTP, if needed. The firewall cares not if the packet is a Chan_SIP or Chan_PJSIP generated packet.

I’m pretty sure, like 99.9%, that if you actually detailed the issues you where having when trying to implement PJSIP that the actual causes of those issues are poor configurations and understanding on how to configure/setup PJSIP.

1 Like
10

Thanks. We’ll dig deeper and I’ll report if and when we find something specific.

11

Agree with above, what security features are you turning off?

We’re running watchguards and ubiquiti routers with everything like IPS/DPI/gatewayAV on and configured with nearly no specific attention paid to the phone system with the assistance of a regional tech rep from WG who was not familiar with freepbx and have no issues running pjsip. We made one exception for DPI coming from the PBX (there is no need for it).

We deployed on pjsip right from the beginning and aside from learning asterisk/freepbx on the fly and some initial config issues have had no problems with a pretty damn locked down network and pjsip. We even have on particular situation where it’s going thru two routers and being double NAT’d and it still has no issues.

The only complaint I’ve had in the past 8 months of running it are that everyone hated our first IVR layout (screw them it’s not my fault people dont listen) and our S500s occasionally drop the call when you hit the volume buttons.

12

Ok, ok, ok :grinning:

We’re standing up a new instance of FreePBX so that we can further test with PJSIP. The only caveats I’ll throw out are:

  1. That there have been updates of just about everything involved since our last test, so we may not be able to reproduce things in the same manner.
  2. If everything works now either because things have change in software or because we screwed something up in our initial tests, then I’m happy (either way). I’m always willing to take “yes” for an answer.

-Erik

13

Erik and Andrew,

When I setup my FreePBX system I attempted to get pjsip working with my Cisco VoIP gateway and I could not get it to work no matter what I did. Switching the trunks to chan_sip and it worked out of the box. I run the extensions on pjsip.

I run my system behind a different Cisco router running in address translation mode and port forward the outside SIP port to the PBX. I run soft phone programs on my smart phones. On some remote networks it works on others it does not. On the ones that it does not work I run a VPN from the phone to the Cisco router and it does work over that.

I have no doubt that if I put 2 network adapters in my FreePBX system and one was numbered with an outside Ip address it probably would reduce the number of remote sites that I cannot make a SIP connection to my phone system from without having to run a VPN.

It took a lot of experimentation to get everything working smoothly but it does now.

Andrew and others it is simply not true that SIP handling is identical between pjsip and chansip. I’ve offered configurations and test access before but nobody has taken me up on it and I can only conclude that you all know that there’s differences but prefer to pretend there aren’t…

Erik, if you are going to run a FreePBX system you must accept that a lot of tuning comes with it. You are, to put it bluntly, acting like a whiny child. Sangoma has commercial solutions you can plunk down cash for that work out of the box.

As I see it both of you are in the wrong. Andrew is wrong for pretending there’s no problems with pjsip and Erik is wrong for castigating something he doesn’t understand how to use. And I fully expect both of you to jump up on your haunches and scream at me but at least the truth is out in the open where it belongs.

14

I’m not “pretending”. I am informing you that sip and pjsip are the same in that they follow the SIP RFC implementation(s), again, They follow the SIP RFC. You stated that PJSIP is a different implementation.

That is simply not true. Please remember that you started this thread because you have an issue with me stating why we are supporting pjsip. Which is because digium (now sangoma) has dropped support for chan sip. When I responded to this thread I thanked you for your opinions and doubled down on backing pjsip. I next stated that PJSIP is not a “superset of the more traditional SIP implementations”. Because that is 100% not true. I’m only here giving facts. I have never once said (in this thread) or pretended that there are no issues in PJSIP.

I. Never. Said. This.

Where? You have not offered that up at all in this thread.

I looked through all 31 posts you’ve made on this forum and I don’t see you offering that anywhere. Your first post ever in this forum was about how one of our marketing images did not have the reflection of the lady at a rack in the racks reflection.

I’ve kindly asked you to stop making up information (that I said something I did not, or that PJSIP is “a superset of the more traditional SIP implementations” to push your own agenda (which is I assume “chan_sip” is better than “pjsip”).

Who, in this thread, has screamed at you? Even once?

I’ll leave you with this…

2 Likes
15

“I am informing you that sip and pjsip are the same in that they follow the SIP RFC implementation(s), again, They follow the SIP RFC.”

And I am saying based on experience that they don’t both follow the SIP RFC implementation the same way. If they did then they both would connect to a Cisco voice card. But pjsip does not, chan_sip does. I can provide logs and configurations of the equipment in use.

IMHO chan_sip does not connect to all of the voip sip phones out there as well as pjsip does. I haven’t tried using chan_sip with mine to see what happens but I have seen troubleshooting posts in the past from other people indicating this with their phones. [Shrug]

You made the correct decision to keep chan_sip in FreePBX. But from my POV there seems to be an attitude that someday chan_sip is going to be removed. I am fine with that if you folks want to then look at all of the cases where pjsip doesn’t connect and fix them. I don’t care one way or another which is in use. I just want you to quit telling yourself and others that they are interchangeable because I have proof they are not.

“I’ll leave you with this…”

I believe you misinterpreted that post from the beginning. I was never opposed to the acquisition that 1 liner was a joke but you are apparently not a fan of Dana Carvey and missed it. Or maybe I’m just too old and should stick to pop references that are not 30 years old.

16

Then provide it.

If you look at the direction of how the core module has been coded recently you would see that this isn’t true. In fact at some point in the future Chan_sip would be a separate module youd install if you want to use it.

17

Please do. As someone that has worked with SIP for over a decade at ITSPs and LECs, you’re approaching this wrong. @tm1000 was correct in his statement Chan_SIP and PJSIP follow RFC standards. Like I stated previously, running Chan_SIP then switching to Chan_PJSIP on port 5060 doesn’t change a thing in your firewall. It doesn’t change a thing with the endpoints. There are numerous SIP Stacks out there that different platforms use and they all do the same thing, follow SIP RFC standards. Vonage, Ring Central, Flowroute all run their own choosing of SIP Stacks/platforms as do most ITSPs/LECs.

Honestly, Chan_SIP was feature-lacking compared to the rest of them over the years. Everyone got excited when PJSIP came out because it meant multiple contacts on an AOR except that’s been a standard SIP platform feature for over a decade on most other SIP Stacks.

However, what I do find amazing about the complaints/statements of PJSIP not following RFC standards a certain way is due to the fact a CISCO box is having a problem. Cisco is notorious for not following RFC standards and doing things their own way. coughSCCPcough. In my over decade of experience in dealing with SIP endpoints/systems, the only decent SIP devices Cisco has are the SPA series and they BOUGHT LINKSYS for them.

So yeah, I’d love to see some debugs and logs because I’m curious as to what the real issue is.

1 Like
18

Here’s the reasoning.

Doubt it.

Any real effort just elicits eye rolls.

The whole reason pjsip is terrible is because a Cisco POTS gateway has issues connecting over pjsip. Unsure what the issues are.

19

Hi Tom,

Here is what is working right now (caller ID also works BTW) for the trunks (FreePBX to Cisco)
Note that caller ID requires either
the later version 2 port voice cards or the 4 port voice card (I am using the 4 port card here) I was
using a Cisco 2600 earlier with the 2 port voice cards and I still have it but the voice cards are early
versions that don’t support caller ID so I switched to the 1760.

There is no NAT between the FreePBX system and the Cisco.

Note that DTMF relay DOES NOT work with some phone models.

Note that chan_sip bind port is 5160 and pjsip port is 5060 This is because Cisco’s translator WILL NOT
properly translate SIP/rtp packets from outside to inside if they are not on the standard 5060 port.

Cisco 1760 with 128MB ram. IOS version 12.4.25d

4 voice FXO interfaces configured as follows (hopefully you can read Cisco IOS configuration):

voice rtp send-recv
!
voice service voip
fax protocol pass-through g711alaw
modem passthrough nse codec g711alaw
sip
!
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8 bytes 40
codec preference 3 g723r63 bytes 96
codec preference 4 g726r16 bytes 80
!

!
voice-port 2/0
no battery-reversal
timing hookflash-out 50
connection plar 2255
description trunk 503-445-2255
caller-id enable
!
voice-port 2/1
no battery-reversal
timing hookflash-out 50
connection plar 2257
description trunk 503-445-2257
caller-id enable
!
voice-port 2/2
ring number 2
no battery-reversal
timing hookflash-out 50
description trunk 503-445-2256
caller-id enable
!
voice-port 2/3
!

!
dial-peer voice 1 voip
preference 1
destination-pattern 2255
voice-class codec 1
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
no vad
!
dial-peer voice 2 voip
preference 2
destination-pattern 2257
voice-class codec 1
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
no vad
!
dial-peer voice 3 voip
preference 3
destination-pattern 2256
voice-class codec 1
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
no vad
!
dial-peer voice 11 pots
preference 1
destination-pattern .T
port 2/0

dial-peer voice 12 pots
preference 2
destination-pattern .T
port 2/1
!
dial-peer voice 13 pots
preference 3
destination-pattern .T
port 2/2
!
sip-ua
retry invite 3
retry response 3
retry bye 3
retry cancel 3
timers trying 1000
timers expires 300000
sip-server dns:guessme.pdnit.com:5160

FreePBX running version

PBX Firmware:10.13.66-18
PBX Service Pack:1.0.0.0
Current Asterisk Version: 13.15.0
Module versions 13.0.x

FreePBX Chan Sip Configuration:

SIP Settings:
outgoing peer details

host=192.168.1.6
type=peer
insecure=port,invite
dtmfmode=rfc2833
disallow=all
allow=ulaw

incoming peer details

context=from-pstn
type=peer
host=192.168.1.6
dtmfmode=rfc2833
disallow=all
allow=ulaw

Ip addresses and hostnames have been changed in the above config.

I’m assuming you don’t need to see call setup/teardown logs from a working setup. This FreePBX setup is
running as a virtual guest on an ESXi server.

Now as far as logs from a non-working pjsip setup, I can’t tear into this FreePBX setup to give you that, instead I can setup another vm, install a copy of FreePBX in that, configure it for pjsip trunks and temporarily change the hostname in the Cisco and the Cisco’s IP address. So what version of FreePBX do you want?

PS by the way if I thought pjsip was terrible why would I use it for extensions?!?!? The point is that it doesn’t work in this setup and thus it can’t be an identical implementation as chan_sip. If it’s a Cisco bug then was chan_sip modified to account for nonstandard behavior and if so why weren’t the mods carried into pjsip? I think it more likely that chan_sip was doing it right and pjsip isn’t.

20

"What would you like to see added in FreePBX 15?

And I would use Cisco phones. Why? Simple. Users associate Cisco with higher end stuff and assume that just because it’s a Cisco phone on their desk, that it’s a Cisco PBX"

Both of you please note that Cisco has replaced the SPA phones with the x800 series phones. There are 2 different variants of these phones the SCCP ones and the “multiplatform” ones. They are identical hardware and it is possible (or was, with older CUCM firmware) to upgrade the 3PCC multiplatform ones to SCCP ones but due to some sort of licensing issue it’s not possible to go in the opposite direction. (from SCCP to Multplatform) Otherwise the phones look identical so the “look and feel” issue there is moot. It’s just the installer making sure to get the correct SKU number of the phone is what matters and this isn’t a FreePBX issue.

So what I said earlier on that feature request list is no longer applicable for new Cisco phones. However it’s still applicable to the old 79xx series of Cisco enterprise phones but unlike the new phones those could be converted back and forth from SCCP to SIP:

Because of the current restrictions on converting the new Call Manager phones to SIP and because many people report that SCCP firmware works better on the older Cisco enterprise phones (like the 7900) someone wrote a chan_sccp module.

Including this in the new version 15 would be useful for some people I think.