I want to create a ring group that can still be controlled in the GUI, but the extension can be a ${variable}# (always a external cell number).
The GUI prevents me from adding anything but a number as a ring group extension.
I was thinking I would create an extension, to use with the ring group, that when called dials the ${variable} for me, but am not 100% sure how I would do this yet.
FMFM does not work for the same restriction as ring groups.
I will be researching and update my notes here, but thought I would throw it out to the group, incase someone had an idea on how to make a dialed extension ring a cellphone without FMFM. Any ideas? Thanks in advance!
Goal recap
Ring group in GUI, so users can edit options on the fly.
Extension RG calls is a ${variable} that is already defined as the specific cell phone I want to dial (I can handle the variable creation.)
Not sure if this is what you’re asking, but try creating an extension with Dial set to local/${variable}@from-internal
Test first by calling the extension directly from another internal extension.
in Ring Groups you can put in a cell phone number like you put in an extension in Extension List just put in a # after the number for example 18452226548#
and scroll down and enable confirm call so if the cell phone doesn’t pick up the caller doesn’t go to the cell phone voicemail
if you use FMFM you can let your users control it from UCP and you can also put a BLF on their desk phone to toggle it on or off
You may also try to update the ring group list using the database, database put from asterisk CLI, and see if it accepts variables.
Also, the ring group dialplan isn’t that complicated, create a ring group to have the PBX generate the dialplan and then copy it and maintain it yourself with all custom variables under extensions_custom.conf
This did it for me. I was able to create a small snippet of custom dial plan to
Lookup the ring group destination from the phone book.
Then activate the generic ring group.
To @PitzKey’s point I could have just made my own RG in the dial plan, but this new method keeps the RG controls in the GUI, making it easier to adjust by many.
Actually I got close but not quite there yet. I had my extension hardcoded to my cellphone number, which worked!), but when I added the variable ${DB_RESULT} it fails.
local/5555555555@from-internal WORKS!
local/${variable}@from-internal Fails
[2020-05-19 10:03:40] VERBOSE[5954][C-0004c67a] pbx.c: Executing [LC-1111111111@from-internal:6] Dial("Local/LC-1111111111@from-internal-0000e1ee;2", "SIP/${DB_RESULT:0:10},20,HhtrM(auto-confirm^2001200)b(func-apply-sipheaders^s^1)") in new stack
[2020-05-19 10:03:40] VERBOSE[5954][C-0004c67a] netsock2.c: Using SIP RTP TOS bits 184
[2020-05-19 10:03:40] VERBOSE[5954][C-0004c67a] netsock2.c: Using SIP RTP CoS mark 5
[2020-05-19 10:03:41] ERROR[5954][C-0004c67a] netsock2.c: getaddrinfo("${DB_RESULT:0:10}", "(null)", ...): Name or service not known
[2020-05-19 10:03:41] WARNING[5954][C-0004c67a] chan_sip.c: No such host: ${DB_RESULT:0:10}
[2020-05-19 10:03:41] WARNING[5954][C-0004c67a] app_dial.c: Unable to create channel of type 'SIP' (cause 20 - Subscriber absent)
Once I figure out the forward, I will share my whole process here. I think you’ll like it. Any ideas on what I could do to over come this last issue?
After reading more really really old forum posts, I don’t think FreePBX lets you add variables to the dial field of an extension.
I think to make this work I need to make an extension (let’s say 1111111111) that’s only purpose is to dial another (cell) phone number, that will be stored in a channel variable ${RESULT}. @lgaetz do you have a recommendation on how to add this function to 1111111111?
Using DB_EXISTS the Custom destination looks up CALLERID(dnid) in Phonebook and returns CALLERID(name), which is actually the cellphone number I want the ring group to use + the ring group number I want to send to. (e.x. CALLERID(name)=5555555555:2001200)
I parse the ring group out using DB_RESULT:11 and the call goes to the ring group (perfect)
The Ring Group GUI does not allow for a variable to be used on the extension list. So I created SIP extension 1111111111 in hopes that I could have that extension call the variable cellphone (DB_RESULT:0:10) when the ring group activates it.
This is somewhat convoluted compared to what could be done in strict dial plan, but allows for one Ring Group to serve many Phone Book entries, and more importantly keeps the Ring Group options in the GUI.
Everything about my approach works. The call routes to the right ring group and the ring group calls 1111111111, it is just a matter of making 1111111111 call DB_RESULT:0:10 (created earlier in the dialplan).
-- Executing [5577@from-internal:2] Set("PJSIP/6013-0000002f", "foo=5555555555:2001200") in new stack
-- Executing [5577@from-internal:3] Set("PJSIP/6013-0000002f", "bar1=5555555555") in new stack
-- Executing [5577@from-internal:4] Set("PJSIP/6013-0000002f", "bar2=2001200") in new stack
Have the call go to ring group ${bar2} which includes an extension of type custom with a dial string of local/${bar1}@from-internal
edit - edited to add double underscore in front of the bar vars. On a re-read, I’m thinking that might be necessary, and won’t hurt anything.
I’m running into the same issue. It looks like the GUI Dial field will not accept a variable in the string. When looking at the logs: local/${bar1}@from-internal executes as "local/${bar1}@from-internal"
instead of transforming into "local/5555555555@from-internal".
Is there a hook or override file I can use to transform the custom extension to use "local/${bar1}@from-internal" from the dial plan directly (although I am not sure this would fix it).
This did the trick and yes, the double bars were necessary on the variable set in the first part of the treatment. For future readers the leading bar(s) cause channel variables to be inherited. I needed Multiple Inheritance (double bars) for this to work.
As a quick service to anyone following this thread, we’ve discovered that you can’t reference a channel variable directly in the dial string of a custom extension. This came as a surprise to me, because you certainly can ref a variable in a normal dial when writing dialplan. The reason this fails is because when you define a dial string for a custom extension, it doesn’t write it directly to a dial application in extensions*.conf, it gets written to the AstDB and then referenced indirectly on the dial. Here is what database entries look like for a custom extension:
First determine what device(s) to dial:
58448910*CLI> database show AMPUSER 6007/device
/AMPUSER/6007/device : 6007
Use case (Goals): Consolidate several RGs that all “work the same” (same message, cadence, etc.) into (1)one RG that (2)remains accessible/editable from the GUI.
Dependencies:
Phonebook: an entry for the incoming DNID under Number and the ring group + destination (cell phone) under the Name. [ringgroup]:[destination] e.x. ringgroup 200 wanting the call to go to cell 555.555.5555 would be 200:5555555555
Extension: Create a custom extension (I did 1111111111) to enable a variable destination. Under the Advanced tab change the Dial field to local/s@custom-dial This will allow 111.111.1111 to call a variable destination, based on your dial plan code, meaning one extension can serve many ring groups.
Ring Group(s): Create a ring group that matches your phonebook entry mentioned above. Assign extension 111.111.1111 to the Ring Group.
Code: I put everything under one .conf file (RGConsolidation.conf) and reference the conf file in the extension_custom.conf (#include FolderPath/RGConsolidation.conf)
Custom Destination: Make a custom destination for [rg-cons] for the inbound destination(s).
Putting it all together:
Call hits inbound route
Ring Group and Destination pulled from Phonebook Name
Call routes to Ring Group
Ring Group dials 111.111.1111, which in turn calls the variable destination ${RESULT3}, via [custom-dial] context
Ring Group complete
That’s it! Its been great for us as we previously had 20+ Ring Groups that were all identical except for the extension used. They are all consolidated to one RG now. Additionally keeping the treatment in the GUI means that many more of our users will be able to edit the Ring Group settings without having to poke around in dial plan. Using Phonebook makes it easy for end users to edit the matches, Ring Groups and destinations using the GUI or Excel and avoids a remote data source dependency.
