it was an unnecessarily verbose post, please extract the relevant lines for us , its your problem, no ?
Your outbound route and the outbound trunk both have the capability to mangle the outbound number to match the provider’s needs. It sounds like your trunk is not stripping the ‘1’ on the front of the number so that it matches the carrier’s needs.
Note that this mangle could also be done on the outbound route - match ‘1nxxnxxxxxx’ and strip the ‘1’.
"Your outbound route and the outbound trunk both have the capability to mangle the outbound number to match the provider’s needs. It sounds like your trunk is not stripping the ‘1’ on the front of the number so that it matches the carrier’s needs.
Note that this mangle could also be done on the outbound route - match ‘1nxxnxxxxxx’ and strip the ‘1’."
Thank you. Sorry if I’m missing something obvious here, but I don’t see how the dialed number manipulation would be different in the two cases, since both calls are coming in on the same trunk over the same native TN, and being sent out using the same custom extension on the same outbound route and trunk.
There is one trunk. Comcast PRI to Digium G100 to FreePBX (as SIP). There is one outbound route. There is only one inbound route for the native TN on which the calls arrive, RCF’d or direct dialed. Extension routes is disabled.
And the successful call log extract as requested ?
Until you expose your “two cases” there are no cases for any one to comment, compare or contrast, no?
So you’ve looked at the manipulation rules for the trunk and the route (in the GUI, not in your head or in theory) and made sure that there are rules in place to remove the leading ‘1’ from the number being sent to your provider.
I’m not talking about anything but what’s on the screen. You should have a rule in the trunk that says “if there is a ‘1’ on the front of the number, remove it.” or something similar. You know that numbers without the ‘1’ on the front work from both the “call to native number and call to RCF’ed number”. Rather than spend a lot of time debating about how it should work, let’s try to duplicate the thing we know works and strip the leading ‘1’ off the number before it gets sent to the provider.
There can be no reasonable response until the OP posts the difference between a call that works and one that doesn’t, anything else is just guessing, either from the OP or the responder. why is it so hard for the OP to do that ? It is obvious that his provider wont process 1NXXNXXXXXX, he needs to fix that first, then work out any further problems. It’s called logic
1 Like
Thanks, Dave. There are no dial pattern manipulation rules on the trunk, none. Nothing in dial patterns, nothing in outbound dial prefix. The Dial Pattern Manipulation tab for the trunk has all fields empty.
I’ve attached what is on the Dial Patterns tab for the outbound route to the trunk. Again, only one trunk and one outbound route here.
To be clear, we can pick up an handset and successfully dial the external number, with or without the 1, configured in the custom extension.
The problem only occurs when an external caller calls the number that is externally forwarded to a number native to the PRI. If that same native number is called, everything works.
so where are your logs for a call that fails, and where are your logs for a call that does not fail? which bit here are you missing ?
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.