Generic outbound CID mapping in stead of CID per extension

is there a way to avoid outbound CID for each extension in FReePBX ? It is a burden to fill-out individual CID for systems with hundreds of extensions, while in fact there is a simple mapping alternative in Asterisk : the variable CALLERID(num) can be “extended” with the DID prefix pattern like this:

suppose DID is 1234567XXX (with XXX internal extension number plan). This means that in case of outbound trunk dialing the local extensions’ CALLERID(num) just has to be extended with 1234567 to complete the public CID.

Remark that on the INBOUND routing a similar mechanism can easily be done via a “custom destation” which removes the same 1234567 prefix before routing to an extension (thus avoiding an inbound route per extension), but on the OUTBOUND route this should be a FreePBX option in the CID field (e.g. “CID prefix 1234567” as alternative for full individual CID).

You can do that similarly in your customized [macro-dialout-trunk-predial-hook].

If you’re not experienced with custom contexts and more of an “Excel” kind of telephony professional, you could also use the “Bulk Extension” feature and update your system using an excel spreadsheet saved as a CSV file.

Put in the extensions, and write a macro in Excel that sets the outbound CID for each extension.

I’m more a kind of telecom engineer who doesn’t like waste of effort and memory for obvious mechanisms that exist for decades in PBX routing logic. DID and DOD just need the same prefix handling to convert public calling and called numbers into private numbers and vice versa, without having to specify those for each extension individually. The current mechanism in FreePBX offers a kind of flexibility that 99 % of users don’t need, so the default should be a common prefix mapping instead of individual mapping. This common prefix mapping is very easily done in Asterisk, so I don’t understand that FreePBX doesn’t offer such a solution per default. Another missing part is national/international number mappings based on ISDN type of number, because otherwise call history logs in end devices do not allow redialing those numbers correctly.

It is very easy to add, basically

[macro-dialout-trunk-predial-hook]
exten => s,1,set(callerid(num)=1234567${callerid(num)})
exten => s,n,macroexit()

if you have other than 4 digit callerid(num)s then add a little logic.

You can also rewrite the inbound calls’ callerid(num) similarly in a small custom-context that ultimately passes the call to 's from_trunk with your adaptations, asterisk provides [from-pstn-e164-us] in /etc/asterisk/extensions.conf you could easily template to suit.

First - these are just opinions. As I reread your post, it occurs to me that I might be missing an important distinction. My first reading of your post sounded like you were looking for extension to outbound CID number mapping where the extension shows up as part of the outbound number. On reading it again, it occurs to me that you might be advocating for a ‘default CID’ instead of using Called ID information per extension. If that’s the case, a lot of the following is way outside what you’re looking for.

I’m not new to this, and I can only think of one place where I’ve worked that could use the kind of functionality you’re looking for. Most of the installations I’ve done needed a single outbound (or a few outbound) numbers that mapped to lots of extensions. The installations where there were multiple outbound Caller IDs mapped to one or more extensions are also relatively common. So, my experience with FreePBX is that ‘one to many’ and ‘many to one’ are relatively common. These cases are handled sufficiently through the mechanisms in the outbound contexts.

Example: Dr’s office - all extensions use the same standard inbound number, except for the in-office lab (which is a series of extensions) and the Cancer support line (which is a single extension). The other 40 phones in the system share the ‘standard’ outbound caller ID set in the Trunk. Note that each extension in the office has it’s own caller ID which is passed to the other local extensions, so the flexibility to have individual caller ID per extensions. This is isnt’ somethat for the 1% - I contend that it’s something that every installation I’ve done wanted and needed. The outbound caller ID is overwritten with the corporate caller ID for outside calls by the outbound trunk, so distance from the extension determines which caller ID is displayed.

The one place that was different was when we had extensions on the desk attached to the Defense Switched Network, and each phone had an extension number (4 digits) that mapped to a DSN number (7 digits) that also mapped to a commercial extension (10 digits). So, having seen exactly the installation you’re describing, I agree that the functionality could be a feature that would be handy.

The difference is that this isn’t the norm any more. These kinds of installations aren’t what most of my customers are looking for. If I DO need that kind of solution, I’d still set it up with Bulk Extensions when I install the system.

Could I write a outbound caller ID context that mapped the extension number to the rest of the phone number? Sure! Of course I could. In fact, I’m one of those saps that would write it and submit it here to be included in the FreePBX system. In fact, as I was writing this, I see that Dicko has written such a beast.

If I was designing a system to do that, I’d put a checkbox on the outbound trunk screen that said something like “map extensions onto outbound caller ID” and replace the last ‘n’ digits with the extension number where ‘n’ is the length of the extension number. Trivial to write, simple to put in place.

Someone should write that, and since this is open source, I think it should be someone that needs that functionality. The alternative is to find someone else to write it, or find a system that does that for you.

Now, as I write this, a number of issues pop up. With standard PBX systems, passing the outbound DNIS and ANI are handled as reasonably atomic operations - the digits passed out identifying the connection are just that - digits. In the SIP header, we don’t pass just DNIS and ANI, we pass a full string with caller ID and identification information (name and number). We set the outbound CID string with both of these items, not just the number. Because of that, there has to be some kind of agreement on how to map the extension into the outbound CID. With that wrinkle added, it might be a little more challenging to NOT do it on a per-extension basis.

As far as the dial-back rules, I’m not sure what the problem is you’re having there. The transforms you’re asking for are trivial to add without a single code change, just through outbound route and trunk rules, unless I’m under-thinking the problem, which is definitely possible.

Yes - that’s what I mean, so I would expect FreePBX to add this kind of logic and extend the trunk settings with 2 extra parameters : the public prefix (in your example 1234567) and the lenght of the internal numbers (1,2,3,…).

It could allso be done with just 1 extra parameter in outbound routes “CLI mapping” = 1234567XXX and 1 extra parameter in inbound routes 'DID mapping = 1234567XXX with number of X’s depending on internal number scheme. And further the inbound routing also needs mappings for CLI, based on national/international number type, otherwise stored numbers can’t be redialed correctly. This is simething tha can’t be done on number mapping only ) it needs the number type parameter.

In my opinion ther should be no need for any predial hooks or custom configurations - that’s more for implementing something special, not for commonly used PBX mechanisms. But maybe I’m just an old fashion telecom guy :wink:

You should maybe do a feature request for the first need if dahdi’s NPI, pridialplan and/or (type)prefix=nnnn doesn’t work for you, the second is already covered by using [from-did-direct] as the context for your ISDN trunk in a one-to-one did (as received on your ISDN trunk) to extension scenario, as to cli presentation and because of all the possible parsings of TON in ISDN around the world, that is probably better done in your dahdi configuration also.

http://www.voip-info.org/wiki/view/Asterisk+config+chan_dahdi.conf

I’m not using Dahdi, because FreePBX is hosted in a remote Data Centre and PSTN trunks are still locally connected at the customer’s premises. So I use an ISDN Gateway which connects as a "SIP trunk’ to FreePBX. This GW does now some number mapping, but it’s not a very clean solution as long as ISDN number type (national/international) isn’t properly mapped to unambiguous SIP prefixes (in fact + for international, N for national and S for subcriber).

In fact I wonder how a direct public SIP trunk is properly connecting to FreePBX, because this is for FreePBX identical to my situation using an ISDN/SIP gateway.

Then I suggest you have a very “custom” situation that will need “custom” solutions, Especially if your ISDN gateway cannot adequately do what you need, given that, a customized version of [from-pstn-e164-us] ( [from-pstn-e164-yourcountry] perhaps ) in /etc/asterisk/extensions_custom.conf would easily handle your needs for CLID manipulation and 1-1 extension mapping.

rasterisk -x ‘dialplan show from-pstn-e164-us’

just localize the NANP type numbering with what you get in your country (your ‘+’, ‘N’ and ‘S’ ) ( if you don’t have a “closed dialing” MSD in your country, you should provide exceptions for those also ) and replace the Goto(from-pstn) s with Goto(from-did-direct) finally replace the context of your trunk to the ISDN gateway with from-pstn-e164-yourcountry and from bash then :-

rasterisk -x “core reload”; tailf /var/log/asterisk/full

make a call and adapt and improve until it works :slight_smile:

IWFM and I am sure it would also fix all your grievances :wink:

tx Dicko - I will try out your suggestions. Just 2 more remarks:

  1. I still believe my situation is not really a “very custom” one. In my current setup (a temporary setup because the GW will become a SIP trunk in the near future) it is the GW that should convert the ISDN number type into SIP headers including proper +,N,S indications like for example Dialogic is doing (ref http://www.dialogic.com/~/media/manuals/dmg30004000/64-0395-01.pdf chapter 5.4.2.2). So the SIP side of the GW should then behave exactly how a SIP provider should present incoming CLI and accept outgoing CLI.

  2. Numbering plans in Europe differ from NAPN and without proper national/international indication it is not possible to detect the difference between them by only looking at digit patterns. I believe that “E.164+ normalizing” should be the default for any PBX system and in fact only needs 3 parameters : national prefix (e.g. 0), international prefix (e.g. 00) and country code. With these is should be possible to offer a “generic” solution for any system without needing custom scripting or modifications in dial plan configurations. And then number redial problems are resolved for ever.

As stated you could try a feature request or two, if your PRI channel is parochially configured and not presenting Asterisk/FreePBX a coherent and consistent DID , then you need to fix that (dahdi can do it well I would contend) , I would also contend your issue 2 and that is the crux of my argument, if you are well numbered like 44 or 46 there is no problem and you just use your obvious national translations if you are a mess like 39 or worse yet 358 then there is no real way of doing that programatically as you suggest, many countries have standardized on “National numbering” in Europe but I have to tell many customers that they need to drop the initial 0 on national dialling in Europe 3 and 4 (but not all) , of course the rules change for 8. 7. 6. 5. and 2. (there is never a problem with 1. because AT&T invented it in NJ 60 years ago but you guys broke the concept locally :wink: ) there is no real way to tell whether the E164 code has stopped after 1, 2 ,3 or even 4 MSD’s, there is no universal way to rely on national prefixes working for both mobile and landlines nor dialing out internationally by any arbitrary , and presumably nowadays not necessarily national, carrier. IMHO there is no easily programmable solution, maybe someone with more patience than me . . . .