I know this has been a long time coming. But since FreePBX had their blog post pushing everyone to PJSIP. I though maybe with the office being closed right now this is the perfect time to transition to PJSIP. But of course as the saying goes the devil is in the details.
The phones shouldn’t be too hard (some offsite phones might be a pain but even so that is a small number). What does seem to be an issue is trunks. I primarily have 3 different trunks.
1: Partner Israel who I’m probably the first to experiment with but the only problem I know I’ll face is that I must make PJSIP use port 5060 or it won’t work with them. They for some reason can’t work if you are on any other port.
2: VOIPInnovations. You would think now being owned by Sangoma they might have instructions for PJSIP but alas they don’t. Their guide for FreePBX still instructs you to use Chan_SIP.
3: voip.ms. Again I find a couple posts but nothing major and apparently they won’t support you if you are using PJSIP.
So therefore my question is are we really ready to move over to PJSIP. Since at the end of the day I need my providers to be 100% ready before I change the ports around.
I helped put the original Voip Innovations FreePBX wiki article together a LONG time ago, and was among the first to try PJ-SIP with them when it became available. Back then (2012 maybe) there were limitations in PJ-SIP that didn’t allow for the setup of PJ-SIP and them. Both ends have made changes and fully support PJ-SIP. Like Aaron said, it ended up being easier to set up the one PJ-SIP trunk than is was to set up the eight different trunks you needed for Chan-SIP to work.
Except that @sorvani actually posted the instructions on this. The OPs statement that they don’t allow it is different than reality - they don’t care and won’t support you trying to set up anything but Chan-SIP. There are dozens of people that have reported success with voip.me and PJ-SIP.
Now, I’d be done with them for a bunch of other reasons, but not “allowing” PJ-SIP shouldn’t be one of them.
No one said they don’t allow it, just that “apparently” they won’t support it. Since the statement was qualified that way, who knows whether it is true. If I call for support and I’m using some SIP stack they’ve never heard of before I would still expect them to have SIP expertise and be able to examine the traffic and tell me if there are any signaling problems.
@cynjut You are correct, that was my mistake. They will “allow” anything but apparently (and I sent them an email but have received no response) they won’t provide support for PJSIP.
Also how do I get away with 1 trunk for all of the connections needed for VOIP Innovations. I get that I could allow multiple incoming that way, but outgoing?
I set up a while ago a trunk for a new client using PJSIP on 5160. I couldn’t get it to work. I called support and there response to me was that you aren’t responding on port 5060 you are using port 5160. It must be port 5060. I changed it to PJSIP port 5060 and it worked. So the conclusion is for some reason they don’t allow it (it might be as dumb as a firewall setting).
I find it a curious dichotomy that voip.ms has pages in their wiki on how to setup Asterisk with pjsip, and can also claim not to support pjsip. Furthermore posts from voip.ms staff on another forum recommend using pjsip.
I actually had to setup 1 for inbound, and then another for outbound. Plus my other outbound trunks with other carriers. So you still need an outbound trunk I think. Unless you figure out a way to use the outbound proxy option.
Its still less work than needing 18 incoming trunks.
On the fact that some providers dont support alternate ports…Vitelity told me that once. I explained that If I used username/pass authentication I could use an alternate port. They replied well we wont support that if it breaks. Lol thats not how sip works. Username/pass auth always uses dynamic ports. Just like 100 remote ip phones. Think they are all on the same public port? Go back to voip school. They are trash anyways. Pretty sure nothing is maintained or supported over there very well. Just a shell of a company bought out 6 times.
I also have a number of Trunks to VI, but the number is closer to two. One for my primary and one for my alternate. One of them is also my Inbound Trunk from them (which identifies all five of the POPs my calls can come from).
I agree that it would be nice to have them offer an SRV record for their inbound, but because different classes of customers use different servers, it might be a little more complicated - it could end up being just as bad as the primary and alternate termination servers they use now.
I just talked to them about this and they said “Submit a ticket with your ideas on a workable solution and we’ll discuss it amongst our technical team and our corporate overlords.” Apparently, they’ve read some of my forum posts.
They’ll let us know what they decide (or I will, if they say “No”).
Could you share a link on the voip.ms staff recommending pjsip?
When I first setup my box I struggled with random dropped registrations from voip.ms using pjsip. After a few days worth of support chats they concluded with:
11:43:31 AM **[Jose]** Ok, that's fine.
We suggest to use chan_sip. It's the best known and our guide is based on this type.
11:44:45 AM **[Jose]** I would suggest you try that. Hopefully will give you better results. Just set
the peer trunk details exactly as they are in the
11:45:33 AM **[Jose]** May I help you with anything else at this time?
That chat snippet was from Jan 2018. I’ve been tempted to try pjsip with them again especially considering @sorvani has a comment in his blog that states:
JaredBusch May 28, 2018, 3:48 PM
Follow up, You also need to set max retries to 0 or the PJSIP trunk can potentially go offline and
But as chan_sip has been flawless with voip.ms I’m sort of hesitant to “fix” that which is not broken
Thanks Lorne. Both the thread and your experience were informative. As its easy enough to change configs, I’ll most likely give it another attempt soon as I would prefer to be on the non-deprecated driver.