PJSIP vs CHAN_SIP feature and functional parity

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.

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?

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.

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

Reddit gold please

2 Likes

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.

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.

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.

What?

1 Like

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…

In my situation, there is a different between chan_sip and chan_pjsip in terms of a the Sangoma Modules and PBXAct wizard. For instance, if you use PBXAct, and use the “Basic”, which is what it defaults to, the only extensions you see are “chan_sip”.

If you use SIPStation to setup your trunks, it uses chan_sip.

You use the Vega Gateway Module to manage your gateways, it also defaults to chan_sip.

If the end goal is for everyone to use PJSIP, then I would assume you would start moving all of your modules in that direction as well.

If you go by the defaults on a PBXAct (14), and setup everything, you will end up everything on Port 5160 and all using chan_sip.

For my setup, I had to specifically change most of the extensions over to PJSIP, and the end goal was to have everything on PJSIP, so that way I would only use PJSIP. Using SIPstation and the Vega Gateway Manager really keeps me from doing that.

There are still a few things that are different in terms of logging or functions in FreePBX. I’ve found a few when trying to work on some paging and the chan_sip had better logs or had more details than pjsip. Like most things, until people use it and open bugs, you really won’t be able to fix them.

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