Multiple DIDs, one route, one extension

I have created an PJSIP extension that I use to receive inbound calls of a DID number. The provider of my DID number is DIDWW. For example, if my extension is 10000 and my freepbx server is, in my DIDWW account I have set the forwarding destination to SIP URI [email protected]

For this purpose I have created an inbound route, where I have set the field “DID number” equal to my actual DID number, and in the “SET destination” field I have selected my extension 10000.

This works. But now I want to forward the inbound calls of another DID number to the same extension. It is not clear to me if it is possible to achieve this without creating an additional inbound route. In other words, I would like to have an inbound route that is able to forward to the extensions all the inbound calls that contain [email protected] in the “TO” field of the INVITE requests.

In order to do this, I should write a list of all my DID numbers in the “DID number” field of the inbound route. However this is not possible, because in this field I can either write a single DID number, or a pattern match (eg _2[345]X) to match a range of numbers, but the pattern match is not useful because the DID numbers can be completely different.

Is it possible to create an inbound route that forwards to an extension all the calls, are only them, who contains that extension in the INVITE message, independently from the DID numbers?

I think you need to provide the protocol logging, as I’d expect FreePBX to treat 1000 a the DID number for the incoming route, at least if you use from-pstn.

Yes you are right, possibly my configuration was not correct. Now I have deleted and created again the extension, setting the extension number equal to the expected DID number; then I configured the inbound route accordingly.

The point is that now I wish to forward a second DID to the same extension without adding a new inbound route. Is this possible? how?

Do the DIDs differ in more than one digit?

Yes, as I wrote:

With the default trunk context of from-trunk or from-pstn, Asterisk will see the DID as 10000. So, if you have an Inbound Route with DID Number set to 10000 and CallerID Number left blank, that route will be honored for all DIDs for which you have set that forwarding at DIDWW.

Look at the DID field of your CDR records to see which DID number was processed by Asterisk.

Thank you for clarifying the meanin of “DID” in this context. I applied your suggestion: I have deleted the extensions and routes in excess and I have left only one extension, the 10000, and one inbound route.

Then I have set the forwarding of 2 different DID numbers to this extension.

Actually it works: the inbound calls of the 2 DID numbers are successfully connected to the extension.
However the behavior is a bit odd and unstable. After dialing the DID number, I have to wait long time (up to 10 seconds) before the extension start ringing. Furthermore, for one of the 2 DID numbers, the caller id shown in the called phone is completely wrong.

Here is the full log.

There is only one relevant call in the log; which is it?

I’m not sure one can comment on caller ID without seeing the full INVITE packet.

I repeated the test after increasing the verbose level

The caller id 447444867185 is wrong. I don’t know where it comes from. I am not even calling from a UK number

It’s coming from DIDWW SBC node:

So, if it is wrong, it is wrong before it gets to Asterisk.

This is a ‘grey’ route and not unexpected. Here’s my somewhat cynical take. Vodafone generously offers free calls to Ukraine; see

Some enterprising bloke in the UK figures he can take advantage, setting up a GSM gateway in his garage and selling cheap termination to UA. You make a test call to your UA DID from CH mobile; the operator (using a least cost routing algorithm) sends the call via the UK grey route. Of course, there is no control of caller ID so the number sent is the 07444867185 SIM in the gateway.

Even if the CH operator tried a high quality route first, it likely failed because the Russians blew it up, so they failed over to the grey route. You’re lucky that the call went through at all.

I made attempts to call your DID via three routes that I was reasonably sure to pass CLI, but all failed. A call via LANCK Telecom “Prime” succeeded, but I don’t know much about them. If you see a number ending in 7100 in your CDRs, it worked (please don’t post the number). Otherwise, there are a few other paths I could try.

Thank you very much for the analysis. What is important for me is that such unstable behavior is not caused by a wrong configuration.

By the way when the call was start ringing with big delay I was puzzled to see that during this unexpected waiting time the full log didn’t show any clue of an incoming call. Now I understand that this delay was caused by the routing and not by Asterisk.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.