Freepbx tries to call a PSTN number as if it was an extension


This topic is related to the same freepbx installation as

I have configured

  • an extension (10000)
  • 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: 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.

Here is the complete full log: extension instead of PSTN - FreePBX Pastebin

Asterisk uses extension differently form FreePBX. What it actually means is there is no outbound route for that number.

Probably need to take look at;
an outbound route matching any dial pattern, linked to the SIP trunk

This is the dial pattern settings of the outbound route

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.

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 :wink:

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:

lines 365

2022-11-09 19:40:49] VERBOSE[735] res_pjsip_logger.c: <— Received SIP response (493 bytes) from UDP: —>
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)
Reason: Q.850;cause=34
P-Asserted-Identity: “CID:+39yyyyyyyyyy” sip:+[[email protected]](mailto:[email protected])
Content-Length: 0

Hanguo cause 34


It looks like things break at

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).