Your router is dropping your connection after 15 minutes. There is a setting that you can turn on that will make the router aware of your traffic - I just can’t remember which one it is.
This is a well-known configuration problem that we’ve solved quite a few times. Try looking for ‘15 minute’ in the search bar and see if you can find it.
It doesnt seem like it would be the router. This is happening in multiple locations not just one. It was working fine with our old service running the older version of FreePBX. The new version however is doing this.
I have looked a ton for this issue and have found many answers, a lot of them seem to point to a session timer but I added that yesterday and that doesnt seem to have fixed the issue either.
It’s not a router setting It’s an Asterisk setting. The default is something like 3600 seconds, which is too long for the router to maintain the session. Dropping it to 600 seconds solves it. It seems to me it might have something to do with “QUALIFY=” on your trunk.
Yes, I have read through that thread a few times. I have done the Session-timers=refuse part and that did not make a change. I see some people noted that on asterisk the file /etc/asterisk/pjsip.conf could be modified but I have yet to be able to figure out how to do that through the CLI.
This does not seem like a reasonable fix to an obvious issue with this system. There must be a more permanent fix that is not going to require me to either change the technology I am using or to have to rewrite a file constantly.
We picked this system specifically so we could use pjsip, going to Chan-SIP is just not worth it. We might as well stick with our antiquated system that works ok.
You are aware that PJ-SIP, while being the SIP technology goal, is not a mature technology yet. Using a hammer when a screwdriver is a better choice is doable, but may not be the best tool for the task. In the specific configuration you have, Chan-SIP may be a better tool for this specific application. Leave the reset of the system as PJ-SIP and add Chan-SIP in for this specific problem space. PJ-SIP is touted to be the replacement for Chan-SIP, but right now, it’s just another way to get where you’re going.
There are lots of other things PJ-SIP doesn’t do well (or at all) so I usually recommend to my customers that we use PJ-SIP for the places it makes sense (like when setting up phones which might need Simultaneous Line Appearance), but for trunks and other places that are set up to deal with the mature technology that Is Chan-SIP, the best choice may well be to use both - after all, there’s nothing preventing you from using one, the other, or both.
Another possibility is that you may need to modify the pjsip-custom.conf file, which will survive a system config rewrite. I think PJ-SIP supports that, so you could try that and see if your changes solve the problem AND survive a rewrite.
That seems like a reasonable way to approach this. One of the main things we want to use from the PJ-SIP is the ability to have extensions with multiple phones as we have a number of people that use phones in many places.
Aside from that feature, I dont see why we cant use the Chan-SIP for the rest. How would I go about setting the system to use Chan-SIP for our outbound calls?
Add it and configure it to one of the “Alternate SIP ports”. After that, you just send the traffic to that port instead of 5060. In the “Advanced Settings” you can turn on SIP. PJ-SIP, or both. Everything’s already there - you just need to turn it on.
Have the inbound routed to your 5160 (5061, 6050,whatever) port on your IP address and Chan-SIP will to the rest.
After that, once again in “Advanced Settings” you should find the SIP configuration tab - go to the Chan-SIP settings and go to town. You may recall that some folks recommended adding some settings - you can do that at the bottom of the Chan-SIP configuration page using a “keywork=whatever” syntax in the additional settings.
You could also change the phone port from 5060 to 5160 (or 5061, etc.). This has the advantage of obscuring the least secure part of your connections - your inbound phone.
It ends up being just like adding any other channel technology - it just sits there unlike you frob the port.