This used to work for me in FreePBX 14, before upgrading to 15.
I’m basically using FreePBX to operate a home office as well as my home phone. Thus, I have two outbound routes with the same provider.
My home extensions are 100X and my office extensions are 10X.
I had set up dial patterns in my outbound route (caller id field) so 100X goes through my home route and 10X goes through my office route. Now when I dial out from my office, I get the “all circuits are busy now” message, but my home route works fine. That said, my office calls rarely, but sometimes go through if I dial from another extension or add/remove 1 at the beginning (which makes no difference as I have both dial patterns, 1NXXNXXXXXX and NXXNXXXXXX). This is baffling.
I understand there’s an addon, “Extension Routing” that addresses this, but not worth it when I only have a few extensions, and routing by callerid/extension should theoretically work fine, as it did for me before.
I’ve scoured the net and forums and can’t seem to find anything. I’ve tried various things, including changing all my extension numbers (in case for some reason 100X and 10X both match now).
Any suggestions or recommendations would be greatly appreciated!
Thanks very much. I really look forward to providing great debug . In all seriousness, I’ve been pouring through log files until my eyes pop out, so having a more intelligent way of parsing it is greatly appreciated! I’ll review this shortly and respond back with any insights.
I parsed the log file. As I’m new I can’t post a link to pastebin, so let me know if you want to see any more details, as I don’t want to spam the forum.
Though, to me this doesn’t explain anything new …
“Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 21”
“TRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 21 - failing through to other trunks”
The channel should not be unavailable.
freepbx*CLI> pjsip show registrations
Outbound routes pointing to separate trunks? Or just with different caller IDs?
If you have separate trunks for a non-technical reason, e.g. they are separately billed, one to the business and one personal: The logged call failed because the From header contained 4169944500 (presumably a phone number of yours), but VoIP.ms requires an account number there; see Outgoing Settings in https://wiki.voip.ms/article/FreePBX_/_PBX_in_a_Flash . Look at the settings for your working personal trunk and adjust the business trunk to match.
If you don’t have an administrative need for separate trunks, I recommend a simpler configuration with one trunk, one route and setting the Outbound CID field for each extension to the desired caller ID.
It’s also possible to have separate routes pointing to the same trunk, with Route CID setting the desired caller ID for the extensions that use that route.
It’s separate trunks (sub-accounts at voip.ms). I hadn’t thought of using one trunk and just changing the CID. It’s a great idea, but I do want to keep the accounting separate.
I have definitely checked many times to make sure that my business trunk is configured the same way as my home trunk. One thing to note is that the instructions at voip.ms are for SIP, but I have switched my channels to PJSIP (maybe I’ll need to go back on that).
Oddly, when I monitor the call flow on my home trunk and dial the same number, the INVITE also gets REJECTED, but somehow still goes through.
Something is obviously not configured correctly there. I noticed there’s a “From Domain” field in the advanced options of the PJSIP settings. I’ll try putting my account numbers in those fields now.
I think I may have found the issue. In addition to the “From Client” needing to be set to my user id for voip.ms, I also set the “Send RPID/PAI” to “Both” (In pjsip.endpoint.conf, this translated to send_rpid=yes) and now my calls are going through both trunks.
Thanks so much for your help, Stewart1 and Sorvani! I don’t think I would have found the solution without your guidance. I’ve been struggling with this for a while and so happy now it’s resolved.
. In all seriousness, I’ve been pouring through log files until my eyes pop out, so having a more intelligent way of parsing it is greatly appreciated! I’ll review this shortly and respond back with any insights.
