PJSIP still has bugs

General Help
8

Because the VSP’s are often not supporting Digium’s version of PJSIP and Digiums PJSIP is not always concordant with those VSP’s , I agree, yes you can bitch to the VSP, you can bitch to Digium, so FreePBX is not really a factor here , by default you choose 5060 for PJSIP, so unless clever you will be stuck in that catch 22 under such in-congruent circumstances, but pragmatically you CAN stay with chan_sip and arrange for it to use 5060 while all this sh*t goes down.

If you have a rock solid solution to make PJSIP work on all Trunks, please post it, until then, . . . .

9

Challenge accepted.

Name a provider and I shall provide. If I can’t I will open a bug with Digium.

1 Like
10

I don’t have a problem with any of my providers on chan_sip, why rock the boat yet as it all works?

11

This is what you said. I asked you which providers and you can’t even give me a list. You just want to tell me that chan sip is rock solid. Way to help the community. Or asterisk. Or digium. You’re just trolling now. You don’t want a “Real” solution for pjsip. You just want to tell people it’s “very buggy”. If that’s your agenda then I will always be there to rebut it because it’s unsubstantiated.

I await proof.

12

You will get no proof from me, quite a while ago I sampled PJSIP, there where too many bugs then, and until I see an absolute need for PJSIP on a trunk, I just don’t need it, it as all experiential, so quite reasonably I shared it, if you believe that I am trolling then that would be you, I personally believe you are wrong in suggesting that. But ultimately to all the other users here, “do your trunks work on PJSIP?”

Please don’t take it personally, without doubt Digium’s PJSIP does NOT work yet with many VSP’s, that is NOT your fault nor Sangoma’s and I never suggested otherwise:-)

13

Hi!

At least with Sangoma phones @tonyclewis has suggested very recently that PJSIP still has weird issues, see

These two posts were in the last 3 weeks…

To me it sounds like it’s not fully stable yet…

Chan_SIP does have issues mind you but they are well known…

Have a nice day!

Nick

1 Like
14

We are talking about providers. Not phones. Also the two issues you liked to from Tony was Tony making an assumption to help the user out. Never said it was 100% PJSIP

15

Are not both just considered “Endpoints” in the SIP milieu , The signalling should be symetrical and ideally be identical, the responses, maybe not so much. Each connection will be parochial, but some without doubt are failing.

Never mind, I am out of here, I can offer no real solution apart from the original one I suggested ( try chan_sip if chan_pjsip fails you)

Good Luck

16

Thanks. Then perhaps because your “very buggy” comment is a thought you had from over a year ago and you apparently didn’t document any bugs about what you experienced to anyone and you aren’t even willing to give me the name of a provider who are you to say it’s “very buggy” a year later. You don’t even know what has been fixed in a year and you aren’t even willing to try. I don’t think anyone should take any comment you have about pjsip seriously.

17

Probably so, but in those last few months, nothing has failed me , so as I say, it is all pragmatic, at some point in the future, when there is an essential reason to use PJSIP, I will perhaps sample it again, please go in peace and stop "ragging on me " :slight_smile:

18

The problem is that if something’s not working, it’s not always easy to get to the bottom of it so you can actually present it as a bug. It probably is one, but nobody is gonna confirm that for you if you haven’t been able to do it yourself.

Nobody wants to end up with a full fledged PJSIP system in production, then have problems and then have to revert everything back to chan_SIP.

If it’s smaller bugs we could live with and wait for a fix, ok, but most of what I read recently seems to be more substantial, things that really affect call quality and that a normal user would not want to live with for long.
E.g. the thread about Sangoma phones randomly unregistering, etc. Those kind of problems can become nightmarish.

19

Is there a PJSIP forum? If not, seems like one would be useful to support the transition and track issues. Appears like PJSIP is a big enough issue to require special attention.

22

I agree with Andrew, just opening a thread to say PJSIP is buggy and having no specific issue with PJSIP is not the right thing to do. What was going on in dicko’s mind?

I did start using PJSIP very early (about two years ago) and I did face a few issues many months ago. Some of these issues were due to PJSIP being different to chan_sip but that did not mean PJSIP was broken (example: assyncronous codec issue with some phone brands) and ONE issue was due to a bug that ended up fixed in Asterisk 13.10.2.

I run two PBXs that are 100% PJSIP (trunk and all) and these boxes (virtual machines actually) are rock solid. I consider PJSIP quite stable already and someone coming here should not feel discouraged by this thread.

1 Like
23

How about a pjSIP trunk configuration for VoIP.ms with a PBX bit behind NAT?

24

I beg to disagree, PJSIP is by far not mature enough to use in production. I don’t know why this is a taboo-like issue, PJSIP doesn’t work at 100% that’s it period, No one is offending no one, no one is saying that Digium is not working on it, etcetera etcetera. I still not pushing any changes on new or old servers to use PJSIP because simple things like BLF doesn’t work as expected.

I don’t understand why everyone took it personal and start saying Dicko’s opinion is wrong also the sentence: [quote=“mbello, post:22, topic:42178”]
What was going on in dicko’s mind?
[/quote]

It’s kind aggressive, I mean should I ask your permission first to say something? Do you need to approve what’s in our mind? Or just because we think different than you we are wrong?

Use the wonders of google and you will find that many people are having issues and dropping the use of PJSIP.

2 Likes
25

@navaismo

All I wanted was the name of a provider. Dicko could not provide that. Nor could he provide what was actually wrong. It’s unfortunate you think it’s ok to just state “pjsip is very buggy” without actually saying what is wrong. You are a developer. How would you feel if people said " @navaismo software is berry buggy". Yeah digium is working on pjsip. But the idea of it being very buggy is news even to digium so if you or anyone feels that way then let’s report some bugs. Just saying it’s buggy doesn’t help anyone. I am baffled you agree with this logic.

Saying “use Google” to find pjsip bugs is a lazy response.

26

I have been using PJSIP (in conjunction with chan_sip) for years with all the phones, soft phones, ATAs and trunks at my disposal. I have devices from Sangoma (obviously), Yealink, Grandstream, Aastra/Mitel, Digium, Cisco, Obihai, Snom as well as a few SIP trunking services, and I have NEVER had serious issues with PJSIP with anything other that the YATE Softphone. In my usage, I can pretty confidently say that the PJSIP driver is solid. I am personally aware of large FreePBX deployments (hundreds of peers) with the chan_sip driver disabled, they work fine.

There are issues though, and many of these take the form of FreePBX integration. Every month or two a ticket appears that identifies a specific pjsip parameter that needs to be exposed in the GUI, or some weird corner case comes up in support that can’t easily be explained, so we try chan_sip and find it works. Whether someone wants to then do the necessary research to figure out what is going on or just abandon pjsip depends on their patience and knowledge level. Until you go through the effort to figure out the exact mode of failure, you can’t say there is a bug in either the driver or FreePBX. I have seen a few credible reports from knowledgeable users that take the form “pjsip doesn’t work with X device”, but with no more information than that it is irresponsible to say there are bugs in pjsip or FreePBX when it could just as easily be a phone firmware or config issue.

When someone posts a problem with PJSIP, the recommendation will first be to try chan_sip. That is a reasonable diagnosis step, but need not be the final solution. If chan_sip works, then it will be up to the user and their knowledge level to continue the debug and determine why one works and the other does not. Human nature being what it is, most will opt for the easy solution, but the product is only furthered by putting in the extra effort and identifying issues for the benefit of future users.

4 Likes
27

I myself agree, that was intended as a reply to a poster having trunking problems over PJSIP. For the life of me I can’t find the original post. I composed it on my phone and I am an insomniac, and possibly stumble fibgured,

Otherwise I agree, any one who started such a thread should be bought to task if it lacks context.

Edit, I notice my ‘original’ post in this thread was edited and

Mod edit: this was taken from New installation reload failed still

Was added.

It would have been less misleading if that had been done when split, akso where I the Mod, I would have chosen a less polarizing title. But thank you Mod. For clarifying.

28

Hi!

And that’s not what he did… Those messages were split from another thread…

Please look at the second line of “dicko’s” first message on this thread…

You mean Andrew’s mind (I am pretty sure he is the one who split the thread)…

This was going too off-topic for the other thread so it was split, I would have done the same thing if I could have…

Some people here obviously have a different experience with it than you do and unless you tell me that those two PBX have entirely different phones, endpoints, etc… For now, it simply means that you one of the combination that works…

Interoperability is not always perfect between implementations of the the same protocol (ie PJSIP)…

Heck, for a simple thing like emails it was (and is quite likely still is possible with some MUA (mail clients)) to have pretty weird problems is some situations.

e.g.

We had a pretty weird problem at work that, when some people would send emails, if someone were to reply to them the reply would, possibly, get sent to multiple people…

It turns out it was misinterpretation of how to encode some email headers (this time it was the “From:”) when special characters (accents, diacritics, etc…) were needed in them and when a comma was present…

Not everyone had interpreted the standard (actually a RFC) in the same way…

At the time Microsoft and IBM products were implicated in the specific problem we had at work… Surprisingly Microsoft had gotten it right (or pretty close to) and IBM had gotten it partially wrong…

I could have stopped there but since I was using Mozilla Thunderbird I tried it with it and noticed they had the same problem (IIRC, it was even worse).

I actually enlist the help of the RFC (standard) author to get them to fix the problem as they had initially closed my ticket even when I said I had consulted with him before to ensure my interpretation of the RFC was right…

They were absolutely convinced they get had gotten it right until the RFC author proved them wrong…

When there are interoperability problems or errors in the implementations you have

  • To actually find them (or let them find you :wink:).
  • Report them and be ready to “fight” for them…

Now the problem I had at home with Thunderbird I could wait for it to get fixed but the one at work with Microsoft and IBM I could not…

If there had been such a simple solution such as switching from one stack to another I would gladly have…

That doesn’t mean I would not have reported the problem to them, I would have, but I would not have continued to use it…

That doesn’t mean not using PJSIP in a controlled environment but be aware of possible problems with it, problems you won’t have with the more mature (but less maintained I believe) Chan_SIP…,

I am no SIP/telephony guru but many of them have spoken about this now, enough for me not to consider lightly using PJSIP…

I disagreed with something someone said earlier in this thread which suggested what I did not understand what the problem was about.

I certainly did… For me phones or providers it makes no difference, it’s the same protocol… Some things might change but the underlying protocol stays the same…

At the time I did not reply because it seems like one “side” will not be able to convince the other one there is actually a problem and this thread, at least back then, seemed like it was going nowhere…

Have a nice day!

Nick

1 Like
29

Hi Andrew!
I hear you, but also I understand the other point of view. I don’t know if Dicko or anyone else are able to report bugs, to make traces or generate the coredump file and create an issue on JIRA so that’s why I “understand” the “buggy” sentence. Then I should expect from devs from here and from there asking helpful question to create this issue in JIRA or just end by the “Layer 8 issue”, but no an attack against the user who is complaining about the issues.

You know that I was trying to use the new channel since the GULP creation, so far I’m not very comfortable with the new channel, and I don’t have the time to do the research and provide bug trackers so yes was a lazy response indeed, but not an invalid one.

@lgaetz I’m not even talking about FreePBX all my (ex)servers are plain asterisk, and yes found issues.

So back to the topic we should help people to understand and to create real bugs statements before attacking them and make feel the other people is wrong just because the things that we use works for us and not for them. Maybe dicko was using the aggressive way to get help instead saying “I have an error here and here” he use the “stupid software doesn’t do that” expecting the “You are a fool it works if you do this…”

Anyway I will give it a try later to the new PJSIP channel and I’ll let you know if still very buggy or if now i can eat my words :slight_smile: