Programmable 'Function Button' Dialplan

'Function Button' Dialplan

Do your knucklehead users prefer programmable buttons to memorizing several prefixes for extensions (or even the extensions themselves)? Then this may be just the thing for you :)

The following dialplan code works particularly well on snom phones (and I assume other sip phones), but the general premise is channel agnostic. The goal is use an extension to set a flag which the 'standard extension macro' will check and toggle, upon the next internal call. We need some DB values to serve as flags based on the CID of the user setting the function. We start by setting these persistently.

Set the values we need


[func] ;I have the func
exten => s,1,Answer
exten => s,n,Background(func_instruct) ;for away vm, 2 for busy vm, 3 to page
exten => s,n,Set(TIMEOUT(response)=15)
exten => s,n,Set(TIMEOUT(digit)=3)
exten => _[123],1,Set(DB(FLAGS/${CALLERID(num)})=${EXTEN}) ;set db vals and hangup so some channels get dialtone ASAP
exten => _[123],n,hangup

Now that the DB values are set, the next call to an internal extension will be routed accordingly. The values are no longer persistent as they are reset for every case. (Note: if you have the type of users that I described above, it is important to reset the values to '0' EVERY time. If this behavior is persistent, you and your users will be sorry :))

; Based on 'Standard Extension' macro
; ${ARG1} - Voicemail box 
; ${ARG2} - Device extension(s) to ring 
; Usage
; in main context do exten => 1000,1,Macro(insternal_extension,1000,SIP/SnomDesk) 
; I use variables defined in the globals section so it becomes 
exten => s,1,Gotoif($[${DB(FLAGS/${CALLERID(num)})}=1]?s-NOANSWER,1) ; if flag set call VM
exten => s,n,Gotoif($[${DB(FLAGS/${CALLERID(num)})}=2]?s-BUSY,1)     ; do same but lie and say busy
exten => s,n,Gotoif($[${DB(FLAGS/${CALLERID(num)})}=3]?s-PAGE,1)     ; page the guy, or just dial the interface as per usual
exten => s,n(dial),Dial(${ARG2},20,tT) ; Ring the interface, 20 seconds maximum
exten => s,n,Goto(s-${DIALSTATUS},1) ; Jump based on status 
exten => s-BUSY,1,Set(DB(FLAGS/${CALLERID(num)})=0)
exten => s-BUSY,n,Voicemail(b${ARG1}) ; If busy, send to voicemail w/ busy announce
exten => s-BUSY,n,Hangup
exten => s-NOANSWER,1,Set(DB(FLAGS/${CALLERID(num)})=0)
exten => s-NOANSWER,n,Voicemail(u${ARG1}) ; If unavailable, send to voicemail w/ unavail
exten => s-NOANSWER,n,Hangup
exten => s-PAGE,1,Set(DB(FLAGS/${CALLERID(num)})=0)
exten => s-PAGE,n,SIPAddHeader(Call-Info:<sip:domain>\;answer-after=0) ;substitute YOUR hardware's SDP page value
exten => s-PAGE,n,goto(s,dial)
exten => _s-.,1,Goto(s-NOANSWER,1) ; Treat anything else as no answer

The important thing to note here is tha there are many other functionalities can be added just as I added PAGE. For instance, PAGE will only work in this fashion with snom SIP users, but you could try an GEN_PAGE using DB vlaue 4 and dialplan app PAGE() for dumb/unsupported channels, while still setting headers for SIP channels.

If you have enough programable buttons, you could assign one to every exten in 'func' and save a button.

Some people might say "what's the point" when you can use an extension prefix to do the same thing? I do use prefixes (* for away vm, ** for busy vm, and 9 for page), but it is my experience that my users for the most part dont bother to memorize them, and in fairness to my users (whom I kid b/c I love), other PBX have very similar functionalities.

Current Limitations/Furure Considerations

I'm sure there are a few others, but the most glaring one that comes to mind is the inpracticality of setting this value persistantly without some sort of indication to the user. Even the most clever users may forget they have this set, and inevitably will page their boss with a calling party he is in the process of 'talking smack on'.

That could be for the most part resolved using BRIstuff patch, but if you're like me, bad experiences with certain 3rd party patches, and the current use of other more useful patches like metermaid parking presence (thanks oej and backporter), may make this option less ideal.

If someone could devise a practical way of displaying information on the Snom's LCD screen it would useful for this application, and others.

If you have any questions feel free to drop me a line at: admin (a) ironboundrentals (!) com
...or on freendode: FuriousGeorge

Thanks to [TK]D-Fender for cleaning up some code and making it valid for 1.4
Created by: FuriousGeorge, Last modification: Mon 11 of Jun, 2012 (02:48 UTC) by admin
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+