PJSIP still has bugs

General Help
43

Great! Two issues solved so not “buggy” let’s pretend this never happened ( ¬ ¬) And People on IRC, spanish forums and sometime stack overflow are overreacting.

I just want to say something for your consideration(for everyone not just you): How come do you expect that an user who is using a GUI to make things easier and not dealing with the bare-bones of Asterisk create a complete debug and a ticket into JIRA, let’s be honest FreePBX was built for those who doesn’t have an Idea of anything and just want to click here, click there and PUM! PBX up and running. ¯\_(ツ)_/¯

Keep in mind that in my case I’m not saying “Go back to chan_sip” nein, I just want to PJSIP be more mature and less weird, if you make a dive in the Asterisk forum you can see many posts about PJSIP and also many responses from JCOLP actually solving issues, many times from miss-configuration.

No one likes salty trues from both sides, in my case I will still using chan_sip or maybe start the migration to OpenSIPS and leave asterisk only as a media handler but for now there is “No satisfaction” using PJSIP although looks promising.

( Then again I should start using it and report the “buggy” issues to make it more usable… but the age and the time you know :stuck_out_tongue: )

1 Like
44

I agree.
E.g. every enterprise with Comcast/Xfinity internet service using third party modems will only be given dynamic IP addresses.
In our case the default Comcast modem didn’t work properly using a firewall behind it, so we needed to replace it.

45

After talking with you in IRC about a year ago we changed the default on new installs from PJSIP being on 5060 to chan_sip being on 5060.

46

@tm1000

Yes, that did happen then after much debate it seemed to go back to Chan_PJSIP on port 5060. I’ve installed dozens of FreePBX systems in the last 12 months in ALL cases I’ve had to change the ports on Chan_PJSIP and Chan_SIP to make it so Chan_SIP is 5060.

Here’s two that still had the Dashboard warning from the ones I’ve installed in the last 12 months.

47

We JUST built a new Sangoma 7 distro (that image above is from a new install) and chan_sip is 5060. Not sure what you are installing.

48

So this didn’t happen a year ago after the talk on IRC? Or did it just happen now? Your statement clearly infers that you changed the defaults after the conversation a year ago. My reply is based on that inference and thus shows in the last 12 months that has not been the case.

A year ago the conversation wasn’t about PJSIP defaulting to 5060 on SNG7, it was about the v13 distro. Stating that it is just happening now on SNG7 doesn’t really mean anything outside of only people who install SNG7 will see this. Not anyone using v13 distro, which is what the original discussion was all about.

49

You are right. We didn’t change this. So nevermind what I said

50

Fake news! Thanks for clearing that up. I hope the rest of my comment makes sense, and provides more of a basis for you to begin to understand the problems many people see with PJSIP.

51

@tm1000 and I are on the phone, right now - and both he and I thought that we had changed it back, about a year ago, specifically as a result of the discussion on IRC.

52

Well, we were wrong. We had changed some TLS ports, but PJSIP is on 5060 if Asterisk 13 or higher is installed. Sorry for the confusion.

OUR confusion was the result of a bug in the 14 installer that thought we were ALWAYS installing 11, which is why chan_sip was always on 5060 for our recent installs.

1 Like
53

I’m actually curious now; is chan_sip on 5060 in the latest version of the distro?

54

No. It’s not.

55

OK, I’ll bite:

Long time freepbx distro user, started somewhere in the 5.x series, upgraded all the way to current.

Freepbx ver: 13.0.192.14
Distro: 10.13.66-20
Asterisk ver: 13.16.0

Have a SIP trunk with broadvoice - no user/password authentication, just IP address authentication. Approx 20 Grandstream GXP1400 phones (all in one building, same subnet as freepbx server.) Worked fine for years with chan_sip.

Had a few hours free yesterday, and with the upcoming v14 rollout, and the “unsupported” comments here, decided I should try pjsip.

Moved chan_sip to 5160, enabled pjsip and set to 5060. Converted all extensions from chan_sip driver to pjsip driver - no issues there.

Created new trunk using pjsip - incoming calls work 100%, outgoing calls only work about 20% of the time, DTMF (either incoming or outgoing) doesn’t work at all. Started with pretty standard settings, then tried all combinations of DTMF settings.

Switched back to “old” chan_sip trunk - all calls work 100%, DTMF works well (can’t say 100%, because I don’t think DTMF over SIP ever works 100%!)

My “old” chan_sip trunk outgoing config:

type=peer
trustrpid=yes
sendrpid=yes
qualify=yes
nat=never
minexpiry=30
maxexpiry=3600
insecure=port,invite
host=206.15.150.13
dtmfmode=rfc2833
disallow=all
detectfax=yes
context=from-trunk
canreinvite=nonat
allow=ulaw&g729

Spent a few hours trying to get it working, ended up leaving it as a hybrid setup - all extensions are using pjsip on 5060, and the trunk is back on chan_sip on 5160 …

1 Like
56

Thanks for doing this. Unfortunately this doesn’t give us much to go on. We need to see debug in Asterisk or know the name of the provider.

Disclaimer. I am not saying you are wrong.

57

I put the provider in that info: broadvoice (www.broadvoice.com)

If/when I try to spin the trunk back to pjsip, I can try to grab some debug logs.

  • m
58

All,
For what its worth (maybe very little), I am in final testing of 90 phone system. We are using grandstream phones, sip-tls and srtp connecting to Freepbx v14 (asterisk 13). The phones are all PJSIP and we have had (so far) no issue related to PJSIP. We are using BLF’s etc.
In addition, I just turned up my SIP trunk with Level3 today. I made that PJSIP as well. Initial testing went without issue, i was able to make/receive calls with good quality and DTMF’s seemed to work as well.

Again, not sure if any of these anecdotes are particularly helpful (pro or con) but this is my experience.

1 Like
59

Weighing in on either side is great.

60

Unless of course it was me :slight_smile:

Dear jose , why has this become such a thing? many who have tried PJSIP particular to the big wide world, have maybe had problems, (I personally) , if you haven’t then you have been lucky, no?

The problem lies with Digium ( and perhaps a little with this distro for choosing it as the default) , and the recalcitrant VSP’s ( go bitch at them, they just don’t support PJSIP as presented by Digium yet) and I am sure that eventually Digium will fix it.

But for now chan_sip has not needed a patch of any significance for a very long time, does that not prove it’s robustness? and unsupported or not (that might be questionable) it “Just Works” and has for dog’s years. I suggest that no one needs multiple endpoints on a trunk, so why is it advantageous ?, so absolutely use pjsip for your extensions (if it works for you without flaw) it might just be a pain if used on Trunks in the real world as many have noted exactly that .

JMHOAE

61

Cool, that was a huge improvement over “Don’t use PJSIP yet is is very buggy”.

I just can’t get why you couldn’t name a single one of those “recalcitrant VSP’s”, it would have helped this discussion big time. (I am honestly interested)

62

Because as I have said since time dot. Three years ago it was generally broken, I tried again a year ago, still largely broken, Chan_SIP worked, chan_pjsip not so much, why in the world would I keep trying to fix it, when it works otherwise, I might use it if had function but for a trunk, it doesn’t , I have no skin in the game to replace a perfectly functional system with a wild and so far unproved technology , I really don’t care what trunks don’t work on PJSIP if they work on SIP. Why complicate shit? Everything in this world is pragmatic, if it works for you, use it, if not look for something that does.