Every so often, someone asks whether it's possible to make calls from local extensions produce a distinctive ring that is different than the ring produced by calls coming in from outside the FreePBX switch. A variation on that request is that someone will ask how calls from certain "important persons" (such as the boss) can be made to ring differently than "normal" calls.
The only way to satisfy the first request from within FreePBX was described by mickecarlsson in this FreePBX forum thread:
We have done this by setting all inbound DID's with alert info and have our endpoints configured so that it will trigger the second ring signal if alert info is received. Internal calls will ring whatever the signal is set to on the endpoint as default.
In other words, it's sort of a negative option - you set all external calls to produce a distinctive ring (on the Inbound Route pages) and then if the phone doesn't produce the distinctive ring, you know it's an internal call. While that may be perfectly adequate for many users, perhaps you would like the distinctive ring to be produced on internal calls, not the ones coming in from outside. Or, maybe you'd like the distinctive ring to be produced only if the call originates at a certain extension, or group of extensions.
It is not possible to do this (yet) from within a FreePBX configuration page, not even by adding a module, although any aspiring module writer is more than welcome to take this on as a project. But it may be possible to achieve the desired result, provided four conditions are met:
• The phones or endpoints must support receiving a SIP Alert-Info header, and acting on that header to produce a distinctive ring.
• You must determine the strings that the phones or endpoints expect to see for the desired distinctive ring pattern. A typical Alert-Info string is "Bellcore-dr3", which produces a double ring (like a typical British ring) on some devices (other devices may omit the "d", using "Bellcore-r3" instead). Note that these strings may be configurable on some phones or devices (e.g. Linksys/Sipura models - you must do an Admin login, click on advanced settings, go to the Regional tab, then look under the Distinctive Ring/CWT Pattern Names section to see or change the expected "Alert-Info" strings).
• You must accept that whenever you upgrade Asterisk, you need to use a text editor to look in the file /etc/asterisk/extensions.conf and make sure that the [from-internal] context hasn't changed from the previous version - if it has, you will need to copy the entire [from-internal] context to the [from-internal-original] context in the file /etc/asterisk/extensions_override_freepbx.conf as described below.
• You must be willing to get "under the hood" (or "under the bonnet" as our British friends might say) and do a little bit of manual dial plan construction, as explained below.
If you can meet those four conditions, then here is how it's done. Open the file /etc/asterisk/extensions_override_freepbx.conf (NOT extensions.conf!!!) and enter the following code therein (you will need to change certain lines, but you can cut and paste the sample code below to get you started):
[from-internal]
include => set-alert-if-local
[from-internal-original]
include => from-internal-xfer
include => bad-number
[set-alert-if-local]
exten => 234,1,GotoIf($["${CALLERID(num)}" > "999"]?notfromlocal)
exten => 234,n,GotoIf($["${CALLERID(num)}" < "100"]?notfromlocal)
exten => 234,n,Set(__ALERT_INFO=Bellcore-r3)
exten => 234,n(notfromlocal),Goto(from-internal-original,${EXTEN},1)
;The following three lines must not be changed!
exten => _.,1,Goto(from-internal-original,${EXTEN},1)
exten => s,1,Goto(from-internal-original,s,1)
exten => h,1,Macro(hangupcall)
The lines that will need to be modified are the four lines following the [set-alert-if-local] context tag, which can be duplicated as often as necessary for the number of extensions you have and the various ring patterns you may wish to produce. You need to change them as follows:
All four lines must begin with either exten => extension, or exten => _pattern, — this defines which extension or group of extensions the rule is to apply to. Don't forget the leading underscore if using a pattern. So, where it says exten => 234, you might change that to exten => 1150 to produce distinctive ringing on extension 1150, or you may use exten => _5XX (note the underscore character that must be used at the start of a pattern) to apply the same distinctive ringing pattern to extensions 500-599.
The first two lines define the upper and lower boundaries of what is considered a local extension - in the example shown, anything above 999 or below 100 would not be considered local. Therefore, you can set the distinctive ring to occur only if the call is from a particular group of extensions (a subset of your local extensions) or even compress this down to a single line and do an exact match on a particular calling extension (e.g. the boss!). You can use any of the following comparison operators in these lines: = != < > <= >=
The third line sets the Alert Info string, and must be the correct string for the endpoint. You could have multiple rules to have different distinctive rings for different individual calling extensions, or groups of extensions. If you do stack rules, be careful that the first (and only the first) statement for each extension or extension pattern contains the line number 1 (e.g. exten => 234,1, ...)
The fourth line after the [set-alert-if-local] context tag should be included verbatim, except of course that if you have multiple rule sets then each one must have a unique label here (and that label must also be changed to match in the first two lines after the [set-alert-if-local] tag). So, if I had multiple rules here, instead of using notfromlocal I might use notfromlocal234 (to indicate that this was the label associated with extension 234), so I could keep my labels straight when reading down the list (also that would be easier to auto-generate if anyone ever writes a module to do this).
All the other lines should probably be left unchanged, although I have a feeling that someone will say I should not use the _. pattern in the catch-all line that follows the comment. I was basically following the lead of whoever wrote the [from-sip-external] context in extensions.conf (see the comment in that section of code).
When I wrote this I was using FreePBX version 2.5, so if you have upgraded to version 2.6 or later, be sure to check /etc/asterisk/extensions.conf and make sure that the [from-internal] context hasn't changed - that's what I copied verbatim to the [from-internal-original] context here, so if that changes in extensions.conf then it must be changed here in extensions_override_freepbx.conf as well. Any time you upgrade FreePBX, make sure that the [from-internal-original] context here matches the [from-internal] context in extensions.conf exactly!