I’d like to be able to handle (route) both 10- and 11-digit DIDs, i.e. 800-555-1212 and 1-800-555-1213. I know I can build both DIDs into inbound routes, but I’d like to come up with a better way. For the sake of discussion, you can assume a TN/DID will be one or the other.
So far, the only way I can come up with is to create a trunk from the PBX to itself, and use the Dialed Number Manipulation to strip the 1. Then I can specify an inbound route with a pattern _1XXXXXXXXXX with the self-trunk as the destination.
Since asterisk will match exact DIDs before looking up patterns, all defined 11-digit DIDs will be routed accordingly. If there is no matching 11-digit DID, it would match the pattern, which would strip the 1 and send the call to itself, and then attempt to match the corresponding 10-digit DID.
Looks like you’re in NANP land, in which case setting your trunk context to from-pstn-e164-us will normalize all inbound NANP CID and DID to 10 digits.
I suggest that the best way to do that is to "normalize’ Inbound CallerID(number) using from-pstn-e164-us to “normalize” and modify outbound routes to use 10 or 11 digits as appropriate (locale specific but you can provision both) using the trunk specific rewrites if needed.
Yes, I do indeed plan on normalizing to 10 digits, but that will take quite some time. I’m looking for a way to handle 10 and 11 digits while I’m making the migration. This is a routing PBX with dozens of trunks to individual PBXes.
Would my suggested approach work and/or is there a better way?
Why will it take ‘some time’ ?
Just change the context of the relevant trunk from from-trunk to from-pstn-e164-us , and edit the endpoints to be 10 digit if needed, the DID bulk handler makes that trivial , and then press the red bar (or fwconsole reload fom a shell).
If you are using 11 digit enppoints it might be easier to create a modified from-pstn-e164-custom that doesn’t doesn’t strip (for 11) and adds (for 10 digits) the initial 1
I have 3,000 DIDs spread over dozens of individual FreePBX servers, all of which are currently set up for 11 digits, and I don’t want any unroutable calls while I’m migrating. I’m merging in another few dozen FreePBXes with another 1,000 10 digit DIDs.
Since our upstream providers are currently sending 11 digits, I need to be able to convert to 10 digits for the new PBXes, while maintaining all the existing 11-digit DID routing until they are migrated.
A custom context may be easier than the trunk-to-self - I’ll look into that.
And when I do change the DIDs on each of the PBXes, I plan on using mysql to dump the extensions, pass them through a sed script to remove the leading1, and fwconsole bi to import.
Yeah, that’s what I plan on doing, then after the migration is done, deleting all the 11 digit DIDs. If I can do it with a script/single command over ssh, that makes it easier.
If possible and your trunking providers support it, I would migrate to 11-digit or E.164 format.
For example, 662-266-1234 is a valid number in Mississippi and +66 2266 1234 is a valid number in Bangkok. If both of those DIDs were on your system in 10-digit format, you could not distinguish them.
Either with a working mysql account on mac.hine.com from a remote site or locally on the machine itself Try something like this to build the bulk import file :-
mysql --hostname=mac.hine.com --user=user --password=1234 asterisk -N -s -e 'describe incoming '|awk '{print $1}'|tr '\n' ','|sed 's/,$/\n/' > dids.csv
mysql --hostname=mac.hine.com --user=user --password=1234 asterisk -N -s -e 'select * from incoming '|tr '\t' ',' >> dids.csv
sed -i 's/,1/,/'dids.csv
`
The OP wants an ssh compliant script, I am not aware any method to script BULKEXPORT (fwconsole bulkexport --help not there yet).
basically the ‘incoming’ table is the key data for DID’s an the field in ‘extension’ so mysql could use substring(‘extension’,2) or if all is 11 digits the sed is good enough , if there are any cidnum s then they might need also normalizing.
I think you guys are all speaking different languages. Most of you responding are assuming that each of Brad’s trunk consistently delivers DIDs in either 10 or 11 digit format, and he can just change the context of that trunk and solve the problem. Even then, the e164-us context won’t solve that problem unless the 11 digit delivery includes the + sign.
While Brad’s initial post and responses are somewhat ambiguous, I think that he’s saying that calls can come in from the same trunk with both 10 and 11 digit DIDs delivered, depending upon where they came from initially. I can see that happening if he does a lot of internal routing from one FreePBX machine to another, and the initial upstream providers vary in how they deliver the DID.
Alternatively, he doesn’t understand what you’re telling him to do, because you didn’t give him a step by step set of instructions, but instead just told him to change the context. Regardless, I don’t think the e164 solution will work anyways.
Brad- Assuming that I’ve interpreted you correctly, your best approach would be to review the extentions.conf file in /etc/asterisk. Locate the “from-trunk” (which may be “from-pstn”) and the “from-pstn-e164-us” contexts, and then write your own custom context that can handle both. You’ll then need to change the “context=” line in the PEER details for each your trunks to point to that new context.
If that works, then the remarks in the .conf files are wrong (which isn’t necessarily a surprise):
; from-pstn-e164-us:
;
; The context is designed for providers who send calls in e164 format and is
; biased towards NPA calls, callerid and dialing rules. It will do the following:
;
; DIDs in an NPA e164 format of +1NXXNXXXXXX will be converted to 10 digit DIDs
;
; DIDs in any other format will be delivered as they are, including e164 non NPA ; DIDs which means they will need the full format including the + in the inbound ; route.