Handle 10- *and* 11-digit DIDs

Thanks all, for the discussion!

To clarify, I have two trunking servers that receive 11 digits DIDs from several providers. I have numerous FreePBX servers with trunks to those servers currently set up to accept 11 digits.

I am adding trunks to a few dozen new servers, all of which currently accept 10 digits directly from their current upstream provider. We are porting all DIDs from the current provider on these new servers to one of the existing providers already set up on the trunking servers.

This addition highlighted the need to unify our internal numbering plan, and we decided on 10 digits for clarity’s sake.

I need to ensure there’s no loss of service while we are migrating. Since the new PBXes are already set up to route the 10 digit DIDs, I need a mechanism to get those DIDs, received as 11 digits from the new gaining provider, to 10 digits. Ideally, I would be able to define these new DIDs in the trunking server as 10 digits, while maintaining the existing 11 digit DIDs.

The from-pstn-e164-us context does indeed look for _+1NXXNXXXXXX. The existing upstream provider on the trunking server doesn’t send the +, but does send the leading 1. I can’t simply strip the 1 on the trunk from the provider, since my current 11 digit DIDs would break.

I haven’t done it before, but it looks like I can write a custom context that would conditionally strip the 1, depending on whether a 10- or 11-digit DID existed.

However, is there a reason why my initial suggested approach wouldn’t work? That is, to create a new trunk from the trunking server to itself, with a manipulation rule that strips the leading 1, and set that trunk as the destination on a DID with the pattern _1NXXNXXXXX.

For posterity’s sake, here’s a slightly more concise way of exporting DIDs/extensions:

mysql asterisk --batch -e "SELECT extension,destination,description FROM incoming;" | sed '1 s/\t/,/g; 2,$ s/.*/1&"/; s/\t/,"/; s/\t/","/'

I’d do it on one line, but fwconsole bi doesn’t like to read from STDIN (and using - as a filename doesn’t work either).

If you ONLY get 10 or 11 digit CallerID(number) 's with or without an initial + then an easy solution is perhaps just a simple

exten => _*,1,Set(CALLERID(number)=${CALLERID(number):-10})

but you will; get a ‘warning’ about _* when reloading.

Why not? If it begins with 1, strip it. Otherwise, leave it alone. Something like:
exten => _1NXXNXXXXXX,1,Goto(from-pstn,${EXTEN:1},1)
exten => s,1,Goto(from-pstn,${EXTEN},1)

This seems wrong. The OP is trying to modify the called number, not the calling number.

my bad, rewritten for DIDs as

exten => _.,1,Goto(from-pstn,${EXTEN:-10},1)

Once I have the 10 digit DIDs defined in the trunking servers and the individual PBXes, yes, I will strip the 1. But until they’re defined, doing the above will cause all calls to fail.

Brad,

I would review the extension.conf file, locate the -e164-us context, and then create a custom context that mirrors what FreePBX does with the + sign but instead have it remove the “1.” Then point the trunks that send 11 digits to that context. If you just do a one-liner, you’re likely to miss out on other features that FreePBX includes when processing an inbound call.

If you know what the words “.conf” file and “context” mean, I think you’re good to go. If not, please reply back here and I can give you a more details step-by-step.

Ignoring everything that came after post 1. This may have already been shared.

What you propose will work, but is not as elegant as it could be. Instead of creating a loopback trunk, it can be done with a simple Custom Destination with a target of:

from-trunk,${FROM_DID:-10},1

You can then create a single inbound route to accept 11 digit DIDs and route to the cust dest. It will send the call back to the from-trunk context with only the 10 rightmost digits. If you’re not careful with the inbound route dial pattern, there is a risk of an infinite loop here.

Perfect! That’s exactly what I was hoping for.

1 Like

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