a SIP trunk, which is registered to a SIP provider (rebvoice) to give access to the PSTN.
an outbound route matching any dial pattern, linked to the SIP trunk
I have registered a SIP phone to the extension 10000, and with this SIP phone I tried to call a PSTN number. The calls fails immediately with this error:
[2022-11-07 21:53:02] NOTICE[17371] res_pjsip_session.c: 10000: Call (UDP:188.154.140.137:54174) to extension '+41xxxxxxxx' rejected because extension not found in context 'from-internal'.
Basically, freepbx believes that I am trying to call another extension. How to explain to freebpx that “+41xxxxxxxx” is a PSTN number and not a freepbx extension?
There is surely a trivial mistake of a dummy as I am, however I was not able to find the solution.
The GUI assumes they will be dial patterns, the leading _ in the match patter field is not necessary. The dialed string has a leading + char which doesn’t match any of those strings. X is a digit.
EDIT
I have to change this comment because I had written that adding the underscores had solved the problem, but instead it is still present. By mistake I did the test using a different VOIP service.
Sorry for the confusion.
Furthermore, I realized that the underscores are not accepted by freepbx: after submitting and applying the changes, when I open again the dial pattern settings, I still see the previous configuration (without underscores). What did I do wrong? I Wrote “_XXXXXXXXX” instead of “XXXXXXXXX”
I did more tests but I was not able to find a good dial pattern that always works.
Can somebody please suggest a universal dial pattern, which can match by 100% any international number with “+” or “00”?
Any number will be resolved via e164 as +{countrycode)(national number). 00 is a localized interpretation of the meta character ‘+’ (just like your cell phones work when outside your country) so that depend on your VSP, 00 in most of the world but 01 if your VSP is NANP like. Your ‘national number’ will never have a 0 at the start if you think it does, remove it
Ideally, get with your VSP and identify if they accept E164, if they do, ‘normalize’ all your outbound routes to +XXXXXXXX. but also allow rewrite dialed numbers beginning with 00 to strip that initial 00 and replace with + . Do that also in reverse with incoming calls replaceing + with 00 if that is what your users expect, so redials work.
Thank you, I solved the pattern matching setting 2 patterns to match any international number starting with either + or 00.
Now I have another problem: when doing outbound calls, sometime they work, sometimes they fail, playing a message that “all channels are busy”. The called number is exactly the same in the failed calls and the successful ones: the failure is random and it can happen either when calling with 00 or with +.
Why are channels busy? Nobody is using this freepbx except me.
2022-11-09 19:40:49] VERBOSE[735] res_pjsip_logger.c: <— Received SIP response (493 bytes) from UDP:77.72.169.131:5060 —>
SIP/2.0 415 Unsupported media type
Hangup cause 127
line 500 1. Call-ID: 80a84731a9034953af430efa4db3bebd
where Asterisk sends an initial INVITE with no SDP. I know no way of making that happen, so I’d suggest it is either a bug, or you’ve failed to load a critical module.
This is basically one of your other topics, but I thought you’d said that getting the routes right fixed that, even though I noted that didn’t explain why it broke.
What can I check in my freepbx installation to understand if some critical module is not loaded?
The problem you mention is that the match pattern was wrong, so the PSTN number was wrongly interpreted by PBX as an extension number. Now this problem is gone. In fact, in the latest log I posted here, you can see that the number is correctly interpreted as a PSTN number and the call is tentatively forwarded to the SIP provider (rebvoice).
Yes, I see that the cause is "> Cause No. 34 - no circuit/channel available.
This cause indicates that there is no appropriate circuit/channel presently available to handle the call.".
The point is: which setting should I change in my freepbx to fix this? And why the problem happens randomly, and in many cases the calls are successful?
This is at least a tertiary effect. The primary observable cause is that lack of SDP, for which I know no cause. The secondary one is the unsupported media type response (there is no media type!). The tertiary one is service unavailable, cause 34 response to the upstream side.