macro-tl-goto-voicemail-direct Bug?

true, im just not sure why the hell that script even exists.. theres already a friggen macro-tl-goto-voicemail in the system. I am baffled that someone somehow justified this getting into the scripts for everyone to use when tl-goto-voicemail already does exactly the same thing. The only difference is a 3 second delay.. NOT needed by anyone running thirdlane. In truth the only reason you need a delay like this is because people are using attended transfer to send the call to voicemail which is the incorrect method anyway. Instead you should be using blind transfer to send the call (unless your phone sucks so bad it is incapable of blind transfers). So instead of training idiots... we have another script slowing down the gui... yaay!

my suggestion is don't use that script. Use tl-goto-voicemail, and tell you users to blind transfer. This is an abomination of code written by someone and definitely did not get QA'd by me :)

Maybe I'm just missing something but I saw macro-tl-goto-voicemail and I didn't think it did what I want.

It appears to be for sending calls to a particular mailbox. I wanted to send calls to the mailbox specified in the feature code. So:

*96101

to send the call to voicemail extensions 101.

macro-tl-goto-voicemail-direct does that it just didn't have the multi-tenant stuff in it.

Chris

ok, for the record.. i mistyped the macro .. its tl-transfer-to-voicemail that you should be using

to answer your question:
oh god no.. you realize what happens if you make a feature code 101 when you have an extension 101?

only 1 of those 2 are going to work, either the feature code overrides 101 and you can never call the extension, or the enxtension overrides the feature code and your never going to run this script.

there can be only 1 101 extension.. feature code or user extension.. its still an extension.

here is how i use tl-transfer-to-voicemail

i set up a feature code (assuming 3digit extensions in the 100 block) _71XX that uses this script and set the invoking call length to 1. that means that when you do a blind transfer to 7101 youre sending them directly to mailbox 101, if you dial 7102 your sending them to mailbox 102 etc. 1 feature code not a feature code for every extension. Additionally these scripts have the 'o' extension which allows someone to 'zero out' of voicemail and reach an 'operator' that you define. This is completely missing from that mis-made added macro.

I think you may have misunderstood what I wrote.

The feature extension is *96.

So *96101 sends them to voicemail for 101.

Same idea as your 7 prefix. I just didn't have that option to specify prefix using the old macro and I was very much under the gun when I ran into this today so I just stuck with the *NN model.

Chris

but to do it that way you'd have to do it dozens of times once for each extension plus no operator handler. you are much better off with a nice 1-liner that can do all your extensions and doesnt require alteration every move/add/change =)

I guess I'm still not understanding. I think what I'm doing and what you suggest work the same way.

I'm doing a blind transfer to *96101 and you are doing a blind transfer to 7101.

Each is just one line in the rules.

I like yours better just because it looks cleaner and would have done it that way had I saw the other script but I think they both work the same way.

dont forget about the operator handler and the ability to define your own voicemail arguments ('u', 'b', 's')

im just stunned that someone decided that tl-transfer-to-voicemail did not do what they wanted and wrote a half-assed new one that doesnt let you select the invoking digits, doesnt let you specify operator or even support an operator, doesnt let you set the voicemail arguments, and doesnt work in MTE. And they added what? a 3 second lead time because they cant figure out how to use blind transfer? Not only did they write it, but they somehow snowed alex into including this into base as horribly broken as it is. Now here you come along and stumble upon this broke-ass crap when, had it not been there, you would have found the tl-transfer-to-voicemail script and never had a problem.

So your invoking digits are:

_7

and the blind transfer would be:

7101

for extension 101?

I've never really understood what the _ did.

I do like just using a 7 better so I may try and change this going forward.

Chris

ok, invoking digit is 1 heres a brief lesson in dialplan..

_ means pattern

_71XX means 7 1 anydigit0-9 anydigit0-9

you need the _ to use placeholders like X N Z . !

X - match any single digit 0 through 9

N - match any single digit 2 - 9

Z - match any single digit 1 - 9

. - wildcard match 1 or more additional digits

! - wildcard match 0 or more additional digits

this means 1 pattern _71XX for all my extension... not

7101
7102
7103
7104

all littering my feature codes. This means no dealing with this issue every time i move/add/delete an extension because this one pattern covered every extension.

${EXTEN:1} means skip the first digit and all other digits replace this variable

${EXTEN:-2} means return only the last 2 digits of this variable

${EXTEN:1:2} means skip the first digit and return the next 2 digits of this variable

so EXTEN=5025551212

${EXTEN:1} = 025551212
${EXTEN:3} = 5551212
${EXTEN:-4} = 1212
${EXTEN:1:4} = 0255
${EXTEN:3:3} = 555

the invoking field is asking for how many digits to strip from your pattern. So to do it with a 7+extension your invoking length is 1.

Many thanks.

I didn't realize all those rules applied to the feature codes in Thirdlane as well. I've used them for dialing patterns but good to know they can be used here too.