PJSIP vs CHAN_SIP feature and functional parity

General Help
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.

21

13 or 14.
Please post your pjsip config and logs of a failed call (or whatever isn’t working) and then people can look at it to see if it needs a different configuration or something else.
Sure, bugs are possible.

I have recently reported a few that were show stoppers when using inbound registration pjsip trunks, which didn’t work and also a significant one on outbound registration, which didn’t work with authentication set to both our inbound. Those were Freepbx bugs, not Asterisk, and were fixed pretty quickly.
Maybe you ran into one of those.

I’m confident your scenario can be made to work with pjsip.

22

I’m late to the party, all I can say is:
Google Voice and Cisco Endpoint users are making PJSIP sound pretty bad.

In fact, we have had a codec issue with PJSIP, we didn’t spot it right away because we were new to PJSIP, same like every new toy, it takes time to learn.

It’s very simple: everything that offers more features than your current setup is going to be complicated… Imagine going from a D-Link Router to a Checkpoint or SonicWall Firewall. Would you say that these services which are offering much more features but you couldn’t make it work is bad?

23

This post has nothing to do with this thread. The “What I’d like to see in 15” thread is closed. Please don’t hi-jack a thread that has nothing to do with the thread topic. Additionally the 79XX series are EOL and unsupported, even by Cisco. So no one is going to try to make old phones that are not even supported by their maker work with EPM if they aren’t in there.

As well, there is no Chan_Skinny/SCCP/MGCP support in FreePBX. If it was going to be added, it would have been added a long time ago.

24

Actually, yes. I wanted to see those per my exact statement in my previous post to you about this issue. So far I see a device config and some SIP peer configs. What I don’t see are these logs for PJSIP that you said you had and could show. At this point, we’re still missing 50% of the picture here.

Please provide the logs/debugs and configs for PJSIP!

1 Like
25
  1. Google voice is something hacked together via reverse engineering so it is bound to fail no matter what. Also it only works through a patched version of PJSIP and does not work on chan_sip at all.
  2. SCCP has nothing to do with sip vs PJSIP. Phones that were originally meant for UCM will never work with any sip stack so non UCM system as they will on a UCM system.

tl;dr things made functional as an afterthought or through unsupported means will generally be unstable and awful.

26

Reddit gold please

2 Likes
27

You do realize that chan_sccp is a completely different software package than chan_pjsip or chan_sip don’t you? It is a plug-in like the other two. In theory it could be added to FreePBX right now to run those UCM phones since it has been used to run them with regular Asterisk systems. As Tony said they appear to be going to a plug-in for the chan_* modules in the future so I’m quite sure someone somewhere will eventually plug chan_sccp into a FreePBX system if for no other reason than bragging rights.

28

I will post them later this week. I am curious to see if the fixes you mentioned take care of the issue. As I said I have to setup a test system.

29

They already have. Numerous people over the years have patched Asterisk in FreePBX using a third party module for SCCP drivers to specifically work for those phones. Then it requires modifying FreePBX to deal with those endpoints in regards to dialing them, watching them, etc.

The point James was making is that you will never have 100% feature/functionality on 79XX or any other older Cisco phone that wasn’t originally built for SIP. If you use Chan_SCCP it can’t support all the features the UCM would provide as the PBX. If you use the SIP patch on those phones, they lose features in themselves such as BLF and others.

Cisco bought Linksys years ago for a reason. To have a pure SIP line of devices that were system “agnostic” like other SIP phones on the market. The non-SPA lines, regardless of SIP support or not, are 100% designed with the UCM as the PBX.

On a side note, I’d love to see this type of conversation in the Cisco forums. “Hey guys, I have these Sangoma S700’s and I just can’t seem to get X, Y & Z to work on them with the UCM. Anyone got any ideas? Is there a third party module I can install?”. Oh I’m sure the replies would be reddit gold worthy.

30

What?

31

1 Like
32

Tom I believe Digium patch 13996 corrected BLF and the rest of all that with the SIP-loaded-7900s it also adds features to the 88xx series apparently:

https://issues.asterisk.org/jira/browse/ASTERISK-13145

I don’t have any of those phones at the current time (although I could get a lot of the 79x’s cheap if I had a mind to)

The OP of this thread did not indicate he had any of those - but possibly some in the community have blamed chan_pjsip for the lack of support for these and the OP stumbled over those posts, thus adding to misdirected blame on pjsip???

As I mentioned SPA lines are all EOL at Cisco so if this patch does indeed correct deficiencies in the x8xx series phones it might be prudent to encourage Digium/Sangoma to incorporate this to head off future issues with the x8xx multiplatform phones.

I doubt Cisco bought Linksys for such altruistic reasons. I think they bought them for the same reason they bought Meraki and all those other manufacturers - to strip out the patent portfolio of interesting stuff then toss the remains into the ashcan. Anyone who has seen The Borg on Star Trek should be familiar with the approach…