Hello,
We have a tiny script in Cisco UCCX that enables us to dial the extension that routes to the script, and then CCX reads back the extension from which we’re calling in a loop. This is invaluable for our analogue campus emergency phones for confirming what extension we’re currently stood in front of, and also for using a butt phone on the frame Krone strips - we plug in, dial the script, and the read back tells us the extension we’re connected to which helps prevent errors.
In moving from CCX to FreePBX, can someone suggest how we can duplicate this functionality?
The CCX script looks like this:
This block of code in extensions_custom.conf will read back your callerid number:
[from-internal-saycid]
exten => s,1,Noop(entering user defined context from-internal-saycid)
exten => s,n,Macro(user-callerid)
exten => s,n,Playback(calling&from&number) ; remove this line if necessary
exten => s,n,Answer
exten => s,n,SayDigits(${CALLERID(number)})
exten => s,n,Return
Once you’ve added the dialplan, you can reference it by creating a custom destination with a target of from-internal-saycid,s,1. Enable the return option and submit. From there you can reference this dialplan anywhere in fpbx to create a call flow.
That can be useful too. No need for custom dialplan or extension, but you don’t have the option of sending the caller to another destination after hearing the ext number.
Hi Lorne, thank you. There’s a bit for me to digest here because I’m not familiar with anything but basic FPBX distro config, but you’ve given me plenty to look into. Is [saycid] the dialplan, and it sits within extensions_custom.conf?
Hi Jeremy, thanks for this! It seems that something close to what I was looking for is built in from the start, but I had no idea what to search for. Dialing *65 has the result ‘You’re extension number is ’
I can see in the Logfile - Playing ‘extension.ulaw’ (language ‘en_GB’)
But I’m lost for ideas on why I get the fast busy…ah…no I’m not. (Thinking and typing out-loud here).
We get the fast busy because the extensions are not present in the extensions module.
I realise my initial info is not good enough, so here’s more:
We have 26 Cisco VG224 analogue gateways connected to FPBX distro 16. They run our emergency, always on, phone/lift/refuge devices on campus.
Calls are routed to stations on those gateways as Inbound Routes (for the range of extensions on the specific gateway) that point to Trunks (the Trunks do manipulation and strip the area code prefix, and then just route the final 5 digits to the gateway.
So far as I understood it, that’s how the analogue gateways have to work with FPBX, connected as pjsip at the end of a trunk.
So maybe the Feature Code, great as it is, (and I’m glad I know about it now) can’t work in this present situation. Which is a shame.
Definitely open to config change suggestions though, if there’s a better/different way to go about referencing extensions on these 26 gateways.
Thanks again.
Nathan.
Yes. You need to edit the file, extensions_custom.conf with the above content. Easily done with the Config edit module. After that you need to create a Custom Destination which allows you to ref the dialplan.
Hi Lorne,
I’ve had a go with the instruction and config lines you gave.
I’ve not spotted what number I would dial to get the speak back to work though. Is it still *65, or do I need to specify an extension in the saycid config? (In UCCX we dial 12501, for example).
When I create the Custom Destination and enable the Return option, I get presented with a list to select from - what should I be selecting? Nothing?
A ‘destination’ in FreePBX is something you can use when setting up call flows. If you need a dialable feature code to access the feature, then you would create that with a Misc Application. As for what destination to set after reading the CID, that’s up to you. If you have no more actions to perform after, you can just set it to terminate call.
You might have to throw me another bone here Lorne, still struggling. Been picking at it, and searching for answers on-and-off all day.
Config file edited - Custom Destination created - Misc Application created.
I don’t understand the config file code, but the elements are there and the process appears to flow in the log file, but ends with an error over the destination:
Sorry Mr. Peasant, there was a typo in the dialplan I shared above which has now been corrected. Note that the context name has been updated to read [from-internal-saycid]. Make that single change and do an Apply Config.
and this time I can see that something appears to be reading the numbers out in the loggile, but I don’t hear anything, and then I get the out of order tone
This is so close to working. I can hear other messages when something’s not right, like ‘please try again later’, so it’s odd I can’t hear these digits messages.
It’s almost like I didn’t test anything before sharing it. Try adding this line before the SayDigits
exten => s,n,Answer
edit - I see now that you’ve modified things slightly. The original dialplan shows a PlayBack line, which would have the effect of forcing the channel to answer if it was not already. By removing that step, it’s necessary to explicitly add the Answer line, the SayDigits won’t do it for you.
A colleague had tried to make this work a while ago, but we had no grasp of the need for Custom Destination, nor Misc Application. And we were going down the route of dialing an extension with this little bit of config
You’ve just helped my week end on a good note, and I owe you a drink or two!
Before you go, is there a better way to get the SayDigits to loop than this?
And what do we need to read to starting trying to figure this stuff out for ourselves in FreePBX, it seems off-piste for the WiKi?
If you want an infinite loop, until the caller hangs up, put a label on line 5 (a word in round brackets immediately after the n), and replace SayDigits, onwards, in line 7, with “Goto(label)”, where label is the label you added.
You could also use While(1) before line 5, and Endwhile() after line 7 (which would make Dykstra happier!).
Your colleague’s dialplan would work provided it’s added to context [from-internal-custom], but would only give you a feature code to dial. Additional steps are needed if you want to incorporate the custom dialplan in fpbx call flows.
We’ve got another little build to replicate now where we need to dial in, record some words, and play them back to demonstrate audio both ways is fine. We’ll have a go and see how far we get.
In the mean time, thank you so much for you input.have a great weekend.
Nathan.
Must be getting close now - because some text has gone blue with that change:
