I’m one of those “non-developers” and understand only half of the messages in this thread (ok, maybe a bit more (-; ). So what is the fix for us users right now? Do I just remove T from “Asterisk Outbound Trunk Dial Options”?
I guess most normal users will not be on the edge track. How will I know that the patch made it into the stable track? Will there be an update of one of the modules (FreePBX Framework?)?
Glad this has been looked at. I’ve always removed the tT options when I’ve looked at asterisk in the past, with a SIP endpoint they serve no purpose (unless I miss something) but if an analogue handset is used, then sure, you’d need this to be able to transfer a call.
However, I was of the opinion that “Caller” and “Callee” in this context was utterly wrong. A call should only be transferable from “inside” regardless of direction. If I dial out of the system, only I should be able to transfer it. If you call me, then again, only I should be able to transfer it.
I firmly believe this is something that was screwed up very early on in Asterisk. There is no use case where I can call someone and that person can transfer my call to another person outside of the switch.
So, given that, is the patch that is being tested here going to accomplish this? Nope. If it is removing the clearly incorrect use of T on inbound calls only, it does not prevent the mis-configuration of a ‘t’ for outbound ones. Not as serious a risk of course, but perhaps it could be looked at also?
I would like to provide a caveate for Asterisk, no it is not a bug, it is a feature that works as advertised. That asterisk@home and it’s descendants has “Tt” by default is just a an artifact of that culture that has continued unnoticed for many years, apart from a few (myself and apparently you included) that is a security risk. Please don’t blame Asterisk 
Meh, tricky to agree. I mean nothing negative to the original developer of that part of the code, but it is hard to see the rationale behind it. There should be two types of transfer permission, but they should be conceptualised as ‘internal’ and ‘external’ not ‘caller’ and ‘called’.
Clearly if I call an internal extension, then either party should be able to move the call to another phone, but external calls must work differently. I don’t regard it as a security flaw, more of an oversight and a dinosaur of analogue devices/trunks.
I won’t disagree, but that is what the Schmooze guys just figured out, again it is not Asterisk per se, it is the implementation of any dialplan added to asterisk, i.e. FreePBX
This post by Stewart should be required reading for anyone contemplating this subject:
https://www.dslreports.com/forum/r30703474-
Based on Stewart’s superb explanation of what ‘T’ and ‘t’ actually does, I’ve blanked out both Asterisk Dial Options and Asterisk Outbound Trunk Dial Options and will use the transfer and flash keys instead of *2 and ## from now on.
I’m pretty sure that that won’t work as well as you think, they both rely on the T thing.
I’ve done considerable testing and haven’t found a single case that doesn’t work exactly as expected, both blind and attended transfers. In-call DTMF is totally ignored by Asterisk now and simply passed through. It does also effectively disable ** (disconnect) which I’ve never used, and *1 (toggle recording) which I’ve never used as I record ALL incoming and outgoing calls already.
The thread that @reraikes linked to does indeed give a use case for being able to transfer a call from the external device, but it is an edge case and I’d be interested to know if anyone actually ever did that.
Anyway, so as to make sure I was not talking out of my ass, I just VPN’d a soft phone into the switch and called my cell from it, to make sure that I couldn’t transfer the call. Happy to find that I could not. # and *2 did nothing.
However, I was a little worried to find that *1 did toggle the call recording. That is *1 pressed on my cell gave a beep, and pressing it again gave two beeps. Arguably this could mean that I can receive a call and prevent the agent from having a recording of the conversation.
Sigh.
I have noticed something else:
-- Executing [s@macro-dial:9] NoOp("Local/7001@from-queue-0000003e;2", "Returned from dialparties with groups to dial") in new stack
-- Executing [s@macro-dial:10] Set("Local/7001@from-queue-0000003e;2", "LOOPCNT=1") in new stack
-- Executing [s@macro-dial:11] Set("Local/7001@from-queue-0000003e;2", "ITER=1") in new stack
-- Executing [s@macro-dial:12] Set("Local/7001@from-queue-0000003e;2", "EXTTOCALL=7001") in new stack
-- Executing [s@macro-dial:13] NoOp("Local/7001@from-queue-0000003e;2", "Working with 7001") in new stack
-- Executing [s@macro-dial:14] Set("Local/7001@from-queue-0000003e;2", "ITER=2") in new stack
-- Executing [s@macro-dial:15] GotoIf("Local/7001@from-queue-0000003e;2", "0?ndloopbegin") in new stack
-- Executing [s@macro-dial:16] Macro("Local/7001@from-queue-0000003e;2", "dial-ringall-predial-hook,") in new stack
-- Executing [s@macro-dial-ringall-predial-hook:1] MacroExit("Local/7001@from-queue-0000003e;2", "") in new stack
-- Executing [s@macro-dial:17] Dial("Local/7001@from-queue-0000003e;2", "SIP/7001,27,TtrM(auto-blkvm)Ib(func-apply-sipheaders^s^1),") in new stack
The queue Dials to a Local channel using TtrM, even if the trunk is set to T only.
This menas that an incoming call to a queue , callee can transfer to any number he/she likes.
Anyway to fix this?
Settings -> Advanced Settings -> Asterisk Dial Options - mine is tr, and I just tested - no way to do anything in the Queue even when I tried.
Executing [s@macro-dial-one:48] Dial(“Local/4952@from-queue-00001449;2”, “SIP/4952,15,trM(auto-blkvm)Ib(func-apply-sipheaders^s^1)”) in new stack
Setting the trunk to T is for outbound calling only.
Note that the core patch for this went live today (is no longer in Edge)
Thank you!
But… how do I apply this patch?
Upgrade core…
Hello again,
I’ve upgraded to core 13.0.72, but the callee can still transfer a call to any number he wants, when receiving a call from a queue, as it is dialing with TtrM.
Dial("Local/7001@from-queue-00000002;2", "SIP/7001,27,TtrM(auto-blkvm)Ib(func-apply-sipheaders^s^1),
Should it be fixed by now? Or the patch only corrected the Dial for outbound calls?
It is fixed and confirmed working. You’ve got something else going on here.
Just do what gsnover said:
Just confirmed. The code in core works 100%. Either you didn’t install core 13.0.72 or you didn’t reload or you changed the setting in advanced settings “Disallow transfer features for inbound callers” to “no”
The fact that it’s in a queue makes no difference since it’s hitting macro-dial which is where the replacement happens.
Another thing is if you have any custom dialplan. ANYWHERE.
One thing I didn’t realize is that there are two dial options:
The first is responsible to set the Dial options for internal calls, like queues and extensions.
The second is responsible to set de Dial option when making outbound calls via trunk.
Nothing new so far, it is well explained in the GUI itself.
The problem is that if I set the “Asteirsk Dial Options” to tr, even when dialing from one extension to another, the caller cannot transfer the call, while the callee can.
Or you don’t allow an inbound call to transfer or you don’t allow a call from extension to extension to be transfered by the caller.
I’m not saying that this is wrong, it is just strange that you have to disable internal transfer in internal calls, so you can disable an inbound call to be transfered as well.
OR, I’m doing something wrong?!?!
Posting this here as might be someone else’s doubt as well.
The fix does what you want.
Did you even check for the new setting?
You need to post a complete call trace. From start to finish. Also show me the new setting and what it’s set to.
I fix this issue on my own machine about three months ago by going to advanced settings and setting Asterik dial options to (tr) and Asterik outbound trunk dial options to (T) I’ve tested this many different ways and it does not mess with transferring locally. It prevents all transferring methods from someone who’s not connected to your server. I see with the current framework update you have made your own solution. So my question is if I take this update would it default back or would it change how my current set up is already established. If so what should I do?