IMO, the change you need to make is deleting it altogether, so the Ring Group you added will be seen.
1 Like
Thank you for your suggestion. I’ve followed your advice and cleared out extensions_custom.conf. Now, the calls indeed go through. However, a new issue has arisen: the phone numbers I specified in the Ring Group are not ringing on the recipient side, although I’m not encountering a busy tone at my end. Instead, I hear the music on hold that I set up, indicating that the call is being connected, but not reaching the intended recipients. 
Log with pjsip logger, please.
I appreciate your continued assistance and patience in working through this issue.
Since the log file was quite large, I’ve decided to upload it here: https://we.tl/t-a4VmJ5zsTa
Thank you again for all of your help. 
On line 2164, VoIP.ms rejected your call with
SIP/2.0 503 Service Unavailable
because the From: header was invalid:
From: "NAME" <sip:MY-EXTENSION@PRIVATE_IP_ADDRESS>;tag=7fb3b6c7-d94f-4d47-a1e8-c0c11b1f625e
I believe that they require your username (typically a sub-account name) in the user part. Possibly, with some setting on their portal, they will accept a caller ID in From, but your extension number is definitely invalid.
Now, damn, please listen up!
We’re all trying to help you here. @mahbell, @dicko, @PitzKey , @david55, and I have all usefully contributed to this thread. Why the f**k didn’t you take our advice to make troubleshooting easier?
First, I wasted about 10 minutes confirming that the provider is VoIP.ms. Why didn’t you tell us that in the first post?
But more importantly, in post #10, we asked that you first test with
Extension List:
8XXXXXXXXX#
8YYYYYYYYY#
but you apparently ignored that request and presented a more complex situation with custom outbound routes.
Please test the simpler case. If it fails, post a log, as well as screenshots of the current Outbound Route and Trunk settings. If it succeeds, put the custom routes back in, post screenshots of the current custom Outbound Routes and Trunk settings. If you have changed anything, paste a new log.
1 Like
Hi @freepbx_fan - I’m confused - why use custom dial plan as opposed to the Ring Group or Queue modules?
I’ve built a (moderately) complicated server setup that accepts incoming calls, routes them through to custom languages based on the incoming trunk (to offer customised greetings) then through IVRs and eventually to a pair of chained Ring Groups that offer the call to a number of PSTN endpoints via the suggested Find Me/Follow Me trick on an internal extension. All numbers ring simultaneously, any user that accepts the call then gets connected and the others get a message that someone else handled it.
As the ring groups have an internal extension number already, you could presumably do what you want with one ring group linked to two extensions? Make an internal call to 7878 (the Ring group number) and have the external endpoints ring (in sequence or simultaneously depending on your ring group settings).
I’m guessing there’s a reason you didn’t take that approach but I’m not seeing from your description what that reason was. If you haven’t tried it this might be a simpler setup?
Hi @michthom thank you for your insights. The reason I initially opted for the custom dialplan approach was to enable greater control and flexibility in managing calls, especially considering there wouldn’t be a user registered to the extensions on a softphone.
However, as you’ve pointed out, the FreePBX modules do offer a level of simplicity and are quite capable of handling intricate call routing scenarios. The challenge I’m currently facing is when implementing the Ring Group or Follow-Me features, calls are not ringing on the recipient’s side as expected, but I can hear a non-busy ring tone on my end. Here are the scenarios I’ve tested for a more detailed view:
Reference Scenario: Direct Dialing
Directly dial Prefix1 + Phone#1
➡️ 🎵(Your side hears the ring) ➡️ 📞(Recipient phone rings)
Directly dial Prefix2 + Phone#2
➡️ 🎵(Your side hears the ring) ➡️ 📞(Recipient phone rings)
Scenario 1: Ring Group 
Extensions (Normal / Custom Extension) Follow-Me
Ring Group (7878) calls Extension 1 ➡️ Extension 1 dials Prefix1 + Phone#1 + # (via Follow-Me)
➡️ 🎵(Your side hears the ring) ➡️ ❌(Recipient does not hear the ring)
Ring Group (7878) calls Extension 2 ➡️ Extension 2 dials Prefix2 + Phone#2 + # (via Follow-Me)
➡️ 🎵(Your side hears the ring) ➡️ ❌(Recipient does not hear the ring)
Scenario 2 (bypassing extensions): Ring Group Direct Dial
Ring Group (7878) dials Prefix1 + Phone#1 + #
➡️ 🎵(Your side hears the ring) ➡️ ❌(Recipient does not hear the ring)
Ring Group (7878) dials Prefix2 + Phone#2 + #
➡️ 🎵(Your side hears the ring) ➡️ ❌(Recipient does not hear the ring)
Your thoughts on this would be greatly appreciated!
Please paste a log (including pjsip logger) for the simplest thing that fails. Try in order:
- Ring Group with only Phone#1 + #
- Ring Group with Phone#1 + # and Phone#2 + #
- Ring Group with only Prefix1 + Phone#1 + #
- Ring Group with Prefix1 + Phone#1 + # and Prefix2 + Phone#2 + #
When you encounter the first failure, paste the log for that, along with a screenshot of the Ring Group settings. Also, please explain why you are using two separate prefixes.
1 Like
I’d be very interested to see the configuration of the extensions and in particular the ring strategy / ring time you have set on the extensions themselves and on the ring groups.
In my case I set up individual PJSIP extensions per endpoint, but with no device logged in, as I’m relying on the forwarding to the PSTN numbers.
The extensions have a Find Me Follow Me ring strategy of ringall, with a ring time of 60.
The follow me list for each endpoint contains the PSTN number and a terminating hash character to force the external dial.
I then have an outbound route that matches those PSTN dial pattern taking the call to my SIP provider, and I can see the call attempts going outbound to the PSTN numbers from there which reassures me that FreePBX is working.
On the Ring group I set the ring strategy to ringall also, ring time 60 and with confirm calls set to yes.
Does that help?
Hi @freepbx_fan
The more I think about this the more I’m puzzled as to what’s broken - but I do have prefixes on a couple of my external numbers to force selection of a particular outbound route / trunk, so I still don’t see why you’d be forced to use custom dial plan over the standard options in the FreePBX GUI.
In your test cases when you do not hear ringing at the endpoint you’re calling, do you see the call attempt being offered to the outbound trunk at all?
E.g. in the asterisk full log do you see an attempt to dial on the selected trunk with the prefix stripped off? I’m wondering whether it’s possible the prefix is being left on causing the outbound call to fail?
Thank you, Michael, for your continued support and patience in this process. I must confess, my struggles with this issue are making me question my relationship with FreePBX, which is truly a powerful tool. But I’m becoming increasingly aware that the challenges I’m facing might be due to my own gaps in understanding, rather than the system itself.
I’ve invested a considerable amount of time trying to resolve this, researching extensively and experimenting with different approaches before turning to this forum. Now, a week later, I decided to revisit your earlier suggestions. One change that stood out was setting “confirm calls” to yes. However, this adjustment didn’t change the outcome; my recipients still don’t receive the calls, while I continue to hear the ringing tone on my end.
To provide more context, I have taken screenshots of the configurations for the extensions, the ring group, and the outbound route, in the hope that it might reveal any potential oversights. My preference is to manage these settings via the GUI as it’s simpler and faster. https://we.tl/t-Kq7fNoMrnD
At this stage, I’m feeling somewhat frustrated and disappointed that I’ve been unable to resolve this issue despite my efforts. I genuinely need your expert guidance to help me find the correct path forward. Please tell me what steps to take, and I will follow them accordingly.
Once again, thank you for your support in this matter.
We need to see a verbose call log to see how the call is being processed. You don’t seem to have (or didn’t include) an outbound route for the 90 prefix. But if the external numbers aren’t ringing it means they aren’t receiving the call.
You need to SSH into the PBX and do asterisk -rvvvvvvvvvv and make a call to that ring group and capture the output for us to review.
I’d agree with @BlazeStudios - a log will tell all.
But some things to think about:
Your Follow Me is set up with an initial ring time of 7 seconds - so nothing will happen at all while it tries to ring the internal extensions 781 / 782? On my Follow Me I set Initial Ring Time to 0.
Your ring strategy is ringallv2-prim, which means if the primary extension is occupied the other extensions WILL NOT BE RUNG. Is there a reason you selected this strategy in particular? In my case I use plain old “ringall” - it tries the internal extension for 0 seconds, then gives up on that and dials the external number via the trunk.
Neither of these may be definitive but you need to be intentional on what options you select and what that means in your specific case. I’d simplify and try again.
If you dial 781 from an unrelated internal extension, does that work? If not, paste a log, including pjsip logger.
If yes, as a test, temporarily change Outbound CID for the extension to e.g. your mobile number and call 781 again. Does that work, including displaying your mobile number on the destination phone? If not, paste the log with pjsip logger.
If yes, dial the ring group from the extension. If it fails, paste the log.
If all of the above work, paste the log for the forwarding case.
Thank you all for your ongoing support and willingness to assist. I am truly humbled by the dedication of the FreePBX community, and it is helping to restore my faith in FreePBX.
@BlazeStudios the outbound routes for both the 90 and 91 prefixes have identical configurations, with the only difference being the Route CID. I’ve previously shared the logs a few times, but I will be sure to provide them again in the next few hours for further review. In the meantime, please let me know if you require any additional information or screenshots that could be useful.
Dear @michthom, I want to make it clear that I have been putting a significant amount of effort into resolving this issue on my own and not solely relying on others. The initial ring time and ring strategy were configured based on advice I received. However, I have now revised them to 0 and ‘ringall’ as per your suggestion. I was informed that FreePBX doesn’t consider the ring strategy at the extension level when dialing an external number, but regardless, I’ve made the recommended adjustments. Unfortunately, the issue persists.
@Stewart1, as I’ve mentioned before, direct dialing with prefix1 + phone#1 and prefix2 + phone#2 has always worked, as has dialing the respective extensions 781 and 782. However, I’ve discovered a strange anomaly: When I dial these extensions from MY-EXTENSION, the phone at the other end doesn’t ring. But interestingly, when I dial from an extension that isn’t mine, the calls go through, but without the associated CIDs for 90 and 91. This is certainly worth noting.
I appreciate your patience and look forward to any further insights you may be able to provide.
Nothing else I/we can do without a call trace log of the simplest failing scenario. I’m unclear why you’ve been reluctant to provide one given previous comments.
I have recently updated all modules with the fwconsole ma updateall command, as well as performed a general system update with yum update -y. The verbose log information gathered through asterisk -rvvvvvvvvvv command is based on various scenarios as follows:
When dialing from my extension:
Calling 7878: pastebin.com/CpHPvvM1
Calling 781: pastebin.com/HQ3QC9DY
Calling 782: pastebin.com/MQdJXn2t
Calling 90[number]: Successful call with correct caller ID: pastebin.com/FNwvEK0c
Calling 91[number]: Call reaches voicemail with correct caller ID: pastebin.com/MJW5bsqU
When dialing from a random extension:
Calling 7878: I can hear the ringing, but the recipient’s side doesn’t ring: P1: pastebin.com/T0MDE1sQ and P2: pastebin.com/fTbgtA63
Calling 781: Call gets through, but with incorrect caller ID: pastebin.com/0Dxb7BXE
Calling 782: Call gets through, but with incorrect caller ID: pastebin.com/YrvHDNSg
Calling 90[number]: Call gets through, but with incorrect caller ID: pastebin.com/Pqncdfn9
Calling 91[number]: Call gets through, but with incorrect caller ID: pastebin.com/yNCkRBir
Here are the logs for each situation. Please let me know if you need more information.
What you posted is very hard to interpret. We asked you to paste the Asterisk log for the various calls, with pjsip logger turned on. The Asterisk log file is at
/var/log/asterisk/full
and is also accessible in the GUI at Reports → Asterisk Logfiles.
Instead, without pjsip logger, you chose to scrape the console output instead. Not only that, you did it in such a way as to include terminal control characters, making it virtually impossible to read. And to top it off, your redaction was inconsistent and destroyed syntactic infomation. For example:
e[1;30m -- e[0mExecuting [90PHONE#1@from-internal:9] e[1;36mSete[0m("e[1;35mLocal/90PHONE#1@from-internal-0000018f;2e[0m", "e[1;35m_CALLERIDNUMINTERNALRANDOM_EXTENSIONe[0m") in new stack
Which variable is being set here? To what (the random extension number, the outbound caller ID for the random extension, something else)?
However, I’m pretty sure that calling 781 from your extension failed because it was trying to present the extension number as caller ID on the trunk, and the provider rejected the call:
e[0Ke[1;30m == e[0mEveryone is busy/congested at this time (1:0/1/0)
e[1;30m -- e[0mExecuting [s@macro-dialout-trunk:35] e[1;36mNoOpe[0m("e[1;35mLocal/90PHONE#1@from-internal-00000169;2e[0m", "e[1;35mDial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34e[0m") in new stack
Incorrect??? Couldn’t you at least tell us whether it was the ‘normal’ caller ID for the extension, your main company number, or something else?
I’m guessing that the difference is either that the extensions have Outbound CID in different formats, or there is an Outbound Route above the 90 route that is matching only one of the extensions.
Anyhow, if you want more help, please cooperate.
1 Like
Yeah, I’m not going to try to read through all those in the format they are in. There is just too much garbage that is interfering with the output of the logs.
Get cleaner output in order for us to look at it. Also, stop trying to obfuscate things specially when the # is used and required for what you’re doing. You’re adding another # and there were spots where your obfuscating removed the # at the end in one line but it was there in the next. Not to mention the actual formatting of the number is important to see.
If you’re desperate to hide the actual numbers to avoid web scrapers can I suggest replacing ONLY the public numbers with eg 90xxxxxxxxxx# and 91yyyyyyyyyy#?