How does FreePBX apply changes to asterisk?


I would like to know how exactly changes done by FreePBX are activated in asterisk (using pjsip).

Is there something issued like “core reload”? Or does it depend on the changes done in FreePBX?

Background: after changing and committing them (trunk related pjsip changes), asterisk 18.4 or before is most of the time screwed up (incoming calls are canceled with internal server error) and must be restarted completely to get it working again.

When you Apply Config, FreePBX does issue a reload to Asterisk. However, by default this does not reload pjsip transports, because in the present implementation that drops all calls in progress. Asterisk SIP settings has a parameter ‘Allow Transports Reload’ to control this behavior. But the error you are seeing is much worse than merely dropping existing calls.

Please be more specific. Trunking provider? Registration, or IP authentication? Anything written to Asterisk log when pjsip gives the 50x response? If you have multiple trunks on the system, are the others also affected? Why do you need to make frequent changes to trunking configuration? What are you actually changing? What makes it work again (restarting Asterisk, fwconsole restart, rebooting the entire server)?

If this is an on-site PBX behind a NAT router/firewall, or you have an SBC, the reload might possibly be triggering an unwanted action by the firewall or SBC; provide details.


Thanks for your help!
About your questions: It’s a local box which actually connects via NAT to the ISP (it could go directly, too). To solve the problem, it’s enough to restart the asterisk process (systemctl restart asterisk). At the moment I’m just trying to reproduce it directly on the CLI with asterisk w/o FreePBX. The command “core reload” seems not to be the problem - it’s working fine from asterisk point of view. That’s why I’m asking how FreePBX exactly brings changes to asterisk.

Maybe there is a problem with parameters not supported by FreePBX - therefore I’ve got some configuration in pjsip.endpoint_custom_post.conf, pjsip.registration_custom_post.conf, pjsip.transports_custom.conf and pjsip.transports_custom_post.conf. I’m using 6(!) transports and only one of them is a standard transport - all others are directly configured in pjsip.transports_custom.conf. For each of the transport is the option allow_reload=no set.

I could figure it out meanwhile how it works: After clicking “Apply Config” in FreePBX, the pjsip-config files are rewritten no matter if there was any change or not. This changes the change time of the config files in /etc/asterisk/. Based on the new change time, asterisk really performs a “core reload” - if you’re issuing a reload without touching at least one file like pjsip.endpoint.conf e.g., asterisk seems not to really reload things in question here.

Therefore, after I did a touch of one of the pjsip-files, I was able to reproduce the problem on the asterisk CLI. It turns out, that removing the following two config options in the transport config made the problem disappear (I don’t really need them for this transport):


Further more, I figured out the reason for the 503 I got after “core reload”: pjsip wasn’t able to find a dialog in function pre_session_setup any more after the authenticated Invite of an outbound call was received. This didn’t happen for each device, but for some (they used the user=phone parameter - but this could be incidentally - didn’t do any deeper dive).

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