That matches strings of literal Xs. You need an initial underscore to have them treated as patterns.
SORRY. As pointed out later, the real problem is the lack of the + in the pattern.
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”
You are dialing with a +. None of your routes have a +. You need to add a + in the dial pattern for it to match. X is literally 0-9 only for a match.
You are right, this was the problem. In order to call the PSTN both with “00” and with “+”, I used the “.” pattern.
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.
See full logfile:
https://pastebin.freepbx.org/view/44601f52
lines 365
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
From: “+39yyyyyyyyyy” sip:[[email protected]](mailto:[email protected]);tag=8fbd3b1691dc472e9a9720d65d737d24
To: sip:+[[email protected]](mailto:[email protected]);tag=1a39be8c-4a5a-409d-8faf-da511bf35013
CSeq: 11146 INVITE
Server: FPBX-16.0.23(18.11.0)
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, REFER
Reason: Q.850;cause=34
P-Asserted-Identity: “CID:+39yyyyyyyyyy” sip:+[[email protected]](mailto:[email protected])
Content-Length: 0
Hanguo cause 34
Ref:-
https://networking.ringofsaturn.com/Routers/isdncausecodes.php
It looks like things break at
https://pastebin.freepbx.org/view/44601f52#L349
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?
How did you install it? If you manually installed it, you would need to look at modules.conf.
The symptom on your other topic was one consistent with your current problem not with the wrong match pattern.
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.
If “allow=all” is done on older versions then the INVITE will contain no SDP.
I suggested that on his other topic, but he claims he doesn’t do that.
More specifically, for the trunk, where this was happening before, he says he only uses the tick boxes on the GUI.
See Forward incoming call to PSTN failed although trunk registration successful - #3 by 200765 and the following two postings.
It would probably be better if he took this back to the other topic (and cancelled the solved status).
You need to check with your carrier, it is them that gave the cause 34
Asterisk gave the 34, because the extension had given unsupported media type, because Asterisk had sent an INVITE with no SDP. There was no carrier in this scenario.
Thank you very much, david55 and dicko.
I will make an investigation based on your suggestions, and if I cannot solve it, I will open a dedicated post for the problem of SDP and busy channels.
The current post was opened for another issue that now is solved (invalid match pattern), so we can close it. Sorry that I created confusion reopening the post for issues that are not related to the original one.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.