I am not sure where to go with this. It seems that my original post where i said i was having trouble with outbound calls and parking in general was not correct. The issue surfaced again and when I dug deeper into it, I have the T codes in the advanced settings as I should as described in one post above. But if I initiate a call, try to do a ## blind transfer of any sort, it simply plays DTMF tones to both call legs and does nothing. This is true of either the ClearlyIP phones or the Polycom IP 550’s I was testing with.
What I can verify however is if I use Clearly’s endpoint manager and setup a BLF key for the parking lot, it works fine. Or if I use the transfer button, it works fine. Its just if I use the ## key.
It appears like it is enabled as it should be. In the little help note by the line under Anvanced Settings it actually says the default includes T so you can do things like ## transfers etc. But it doesnt work.
A possible bug? Perhaps another setting somehwere thats blocking it?
Im at a loss.
Thanks
PS If I call in (say on my cell), I can use the ## key and transfer without issue. This is only when I (the internal extension) initiate the call outbound. I just tested by dialing another local extension. I can park fine with ## key. If I have that other extension call me, I can also use ## and park fine. This appears to be only calls going out over PSTN has this issue.
Can anyone reproduce this? I was able to reproduce this on 3 separate FreePBX systems that I checked. ## works everywhere as expected, except when I call out to PSTN, then I (as the caller) cannot do ## or ** or any of those codes.
Ext to Ext - no problem
PSTN to Ext - no problem
Ext to PSTN - won’t work
Not sure if this is an issue with ClearlyIP trunking module, or if its an issue with FreePBX, but I will comment here what I found and how I ‘resolved’ it for anyone else who may run across this. It’s not the correct behaviour either way.
In the extensions_additional.conf file, line 3825 sets DIAL_TRUNK_OPTIONS to the ${DIAL_OPTIONS} value. That works - NoOp confirmed. Line 3827 then sets DIAL_TRUNK_OPTIONS again, this time checking to see if the db key TRUNK/1/dialopts exists, and if so, setting the variable to that value. If not, it sets it to ${TRUNK_OPTIONS}.
The problem is, the TRUNK/1/dialopts key exists, but is null (and TRUNK/2/dialopts, TRUNK/3/dialopts, and TRUNK/4/dialopts). So it sets DIAL_TRUNK_OPTIONS to null, so “T” gets erased from the dial string options.
I was able to verify this on 3 separate PBXs - I did not check versions on the other boxes but I’d expect they are the same major versions, maybe slightly different minor.
Well I’ll have to look at the generated dialplan but this sounds a bit like regression. This was an issue a couple years back. It had the inbound check too early (I believe) and was catching proper user outbound calls in stripping the T option.
You don’t want to blindly add the T option to all outbound calls. If a call comes in the PBX via the PSTN and is sent out to the PSTN again, for whatever reason, then that caller has the ability to transfer calls around.
From what I could glean in the dialplan, it looked like it was checking for the existance of a record in the database, and if it existed (which it does), use its value rather than the Asterisk default (Asterisk Outbound Trunk Dial Options) T. Since the record exists but is null, it sets it to null.
From the little info bubble thing it seems like the setting should be T, unless configured otherwise. What you said about calls forwarded out to PSTN could use the feature code makes sense. Thankfully I havent ran into a case yet where I needed to forward a call to an outside PSTN. I’ve been able to use either Zulu or Clearly Anywhere to handle users on the go.
I would rather not add T to the outbound trunks. Mostly was pointing out that this added T to the database and so the DB_EXISTS function worked as I believe it was intended.