This is actually somewhat common, and I recall learning this the hard way myself years ago. One of the reasons why I don’t take these reports too seriously without a call trace.
3 Likes
OK, so that explains why your test was invalid, but in your OP you reported fraudulent calls having been made, presumably even though Disallow transfer features for inbound callers was set. Do you know what has changed?
Well it became apparent while trying to find the log entries to post.
You just make my Feature Code “32” public 
I am doomed
5 Likes
That’s not the only issue. If you call into an external IVR where you have to enter an extension or account number that happens to contain 32, the call will fail.
If you don’t need in-call transfers, just turn them off. If you do need them in a certain circumstance, set up the system so they are only enabled in that situation. For example, you use Follow Me to ring your mobile when you don’t answer quickly at the office. If you want to be able to transfer calls from the mobile, the forward should use a ‘special’ trunk that allows (only) the mobile user to transfer.
Finally, if there are cases where “Disallow transfer features for inbound callers” doesn’t work correctly, that should be documented and fixed.
@Stewart1 , That is incorrect, in-call feature codes will ( as I already stated ) never be interpreted by your dial-plan, try it 
I never said that they would. If you have in-call features enabled in a situation where your extension has called a remote IVR, pressing keys to control that IVR will trigger the in-call feature, if the codes conflict. That’s why the normal codes start with * and # , because it’s unlikely that the remote system will require that input.
There are also a few 2FA schemes that call your phone and you must enter a code (presented over the web) to proceed. This might conflict with an in-call feature that would allow you to transfer the incoming call.
They are completely separate functions, the in call feature essentially intercepts the audio stream , extracts any DTMF and maps any match to a defined application, if you randomly dial digits inappropriately as this marauder did, apparently while IN_CALL, then by default ## or #2 is a problem,. dialling 32 WILL if so defined do exactly the same thing but is not "well-known’ . You can dial it as often as you want when in the dial plan and NOTHING will happen. if you don’t believe me, then please just try it, I believe you will be surprised.
Yes, but if you make an outgoing call, it answers and the remote IVR asks you to enter your account number which is 32109, then (if in-call transfer is enabled and the code is 32), as soon as you press 32 you will be prompted for a number to transfer to; your intended call will fail.
DGA!!! . if YOU choose a re-entrant code then of course it will be a problem, you have 12 useable dtmf’s and you can use a string of as many as you want. Just use your noggin and replace 32 with 42, it is after all the answer to the universe
There was a recent security bug which did allow ## and *2 transfers from external sources even though the setting was disabled. I can’t remember which module it was in but I updated that module as well as disabled those feature codes. The bug is less than a month old.
Well now I can’t find that exact module update description and it’s bugging me. I could be wrong.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.