QueueMetrics > QueueMetrics installation
Illegal file access: the file is not in the list of allowed files.
QueueMetrics:
Thanks! Can I add this to the User manual? please send an email to our support line so we know how you want to be credited in the manual.
dreaken667:
Go ahead. I'm not interested in being given credit as long as it saves someone else the trouble.
QueueMetrics:
Thanks I will!
ardyhash:
Firstly, thank you Dreaken667 for the excellent writeup, I have been struggling with this for sometime myself and was surprised that Queuemetrics didn't have a solution to offer.
Secondly, I'm afraid I'm still struggling. After adding the proposed dial plan to /etc/asterisk/extensions_custom.conf (I think there may be a typo in the original post, it says to add the dial plan to /etc/asterisk/extension_custom.conf (no s, singular not plural)) and reloading the dial plan, everything remains the same. Watching the logs I can see that the added lines are never executed.
We are using SIP trunks, though from what I gather that should not make a difference, when a call comes in the logs show (DID#)@from-pstn is executed, and based on the messages it is not the dial plan added to extensions_custom.conf.
Do you have any pointers as to what I may be missing?
Thank You,
~ardy
ardyhash:
Thanks again for the excellent solutions (moving forward, fixing the past, and the one-liner for database consistency between past and present), although for whatever reason it wasn't working for me. After some googling I learned of the "from-pstn-e164-us" context which is already written into freepbx, specifically for the purpose of removing the +1. Simply putting your trunks in that context will remove the +1, and the best part about this solution is no need for a shell, it can be done in the GUI.
Alternatively, for those who wish to use your custom context but ran into my problem (the context doesn't stick), they may choose to name the context whatever they wish, and simply place the trunks into that context which they named.
The offices are all closed now, so if I run into any problems tomorrow I'll post once I learn of them, though I don't foresee any issues.
Once again thank you for the excellent writeup, I had been revisiting this annoyance every so often over the past months and was very excited to find this thread.
P.S. From what I gather the reason your method was not working for me may have been, and I'm not sure here, the order of the dial plans in memory. If it matches another dial plan first thats what it will go with.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version