DDI not being picked up by Incoming Routes

General Help
1

Hi,

I’ve been struggling with this issue for about a week now, and although going through this forum and general Googling has come up with lots of things for me to try, none of them have worked for me.

I like to think that my setup it pretty basic:
I installed from the 64bit stable-6.12.65 distro
Asterisk 11.19.0
FreePBX 12.0.76.2
I have one SIP trunk to my provider that has given us a number of DDIs
one ending in 500, a range ending 410-419 and a couple of other singular ones that we may use in the future.

Right now I’m just trying to get some of the 41X range working

PEER details:

username=4420*****500
type=peer
trustrpid=no
sendrpid=yes
secret=*******
qualify=yes
nat=yes
keepalive=45
insecure=port,invite
host=proxy.************m
dtmfmode=rfc2833
disallow=all
directmedia=no
context=from-trunk
allow=alaw

USER Context and Details are empty

Register String:
4420500:****@proxy.****m/4420500

I put the /4420*****500 at the end after reading a suggestion saying that it might help with picking up DDIs in incoming calls. It didn’t brake anything, but it didn’t move me any closer to my goal either. Before it used to just be USERNAME:PASSWORD@HOST

There are 3 incoming routes on the system
A default catch all of any DID / any CID, which I think was there as part of the installation anyway
One for the 020500, which is also the account’s main number anyway
and one for 020412, which I’m testing with

I’ve managed to ascertain that the 500 route is handling all the incoming calls, regardless of what DDI is used.
I though it was the catch all any any route, but I’ve specifically tested for this, and it’s definitely the 500 route. When I switch the destination for calls in this route, they all follow the changes, no matter which number I’m calling in to.
It’s got a DDI (DID Number) value of 4420*****500, because that’s how our provider formats the numbers.

I did a packet capture of an incoming call to the 412 DDI and I can see the right DDI number in the To: User Part, highlighted in blue

capture.png712×536 71 KB

But the main 500 number is in the Request-URI User Part, highlighted in red

I have no idea what the X-DNQ bit in green is.

Is it possible that the Request-URI is being used instead of the To: value?

I’ve seen on 3CX systems (sorry, have I used a dirty word here? :smile:) that one can choose which SIP fields can be used for things like DDI and CID. Is there something like that in FreePBX that I’ve just missed?

Thanks in advance for any help from anyone, I’d really appreciate anything that can get me going on this.

Regards,
Andrew

2

What CID does the endpoint show when you call?

Verify with your provider that they don’t terminate all DIDs to the 500 number before passing the call to you.

3

Hi Serge,

What CID does the endpoint show when you call?

I’m not sure I completely understand the question, but I’ll give it a go:

  • When I make a call from an external phone into the PBX using any of our DDIs, it shows the external number that I’m calling from - as I’d expect.
  • When I call out to an external phone it shows the 020500 number, but that’s because on the Outbound Route we have forced all calls to show the 020500 number. I wouldn’t expect this setting to effect the behaviour of inbound calls though. Does it?

Verify with your provider that they don’t terminate all DIDs to the 500 number before passing the call to you.

I don’t think they do, for two reasons;

  • we had DDIs working on a different Asterisk based PBX before we shifted to FreePBX. It had different Inbound Rules for different DDIs, and they all worked flawlessly. Infact, it had a neat feature where you could specify a pattern match using X, Z, N [x, x-x], etc. for both the DDIs and extensions. So the 410-419 DDI range we have was matched 1:1 to 10 extensions, in one inbound rule!
  • I can see the DDI in the To: User Part in a packet trace with the SIP header (screenshot above) for an inbound call to 020*****412.

Thanks

4

What does the asterisk logs show?

5

You should use the

from-pstn-toheader

context for that trunk.

2 Likes
6

Hi Dicko,

Yes! That’s done it.
Thanks.

7

Serge, Dicko, thanks for your help on this

Regards,
Andrew