Thoughts about having this feature code disabled by default? It will interfere with direct dial to voicemail in the rare cases where there are extensions in the 37X. range and might be considered by some to be a security issue if local users can intentionally or accidentally seize other people’s calls.
This feature code doesn’t need to be enabled by default because it won’t get used in a majority of deployments. This is something, that in its current form, is only usable for internal calls. It won’t seize external call channels. Really, how often does User C need to do a ‘hostile transfer’ from User A and B’s call?
And aren’t we doing this backwards? Why is something in edge repos when the actual functionality and use of it is still being discussed and hammered out? Especially when it is something that could potentially break existing deployments call flow?
Thanks for the explanation. I will test this.
Makes sense. Also, it seems like *37 is already in use by PMS. We’ll have to find another feature code.
In my testing, when extension 200 spoke with 8880001234 and 100 dialed *37200 they were connected to the external caller.
So it does work with external calls.
Isn’t this what the edge repo is for? I wasn’t aware that PMS uses this feature code, nor was I aware about 99 extensions. It is because I don’t use PMS and never really used the UCP softphone.
What type of testing was done for this? Just curious…because the number you presented isn’t a real number and how CHANNELS() matches could cause wrong matches with this.
Are you for real? This is obviously a fake number. Were you expecting me to post my personal cellphone number here?
Could. Indeed. Hence I asked for people to test and report back.
So right now you’re only testing is a system that has 3 digit extensions? Have you tested this with 2 or 4 digit extensions?
https://git.freepbx.org/projects/FREEPBX/repos/core/browse/functions.inc.php?at=release/16.0#1471
[root@freepbx ~]# asterisk -x"dialplan show *37101@from-internal"
[ Included context 'app-callseize' created by 'pbx_config' ]
'_*37.' => 1. Macro(user-callerid,) [extensions_additional.conf:3263]
2. Noop(${CALLERID(num)} is seizing the call from ${EXTEN:3}) [extensions_additional.conf:3264]
3. Bridge(${IMPORT(${CHANNELS(${EXTEN:3})},BRIDGEPEER)}) [extensions_additional.conf:3265]
4. ExecIf($["${BRIDGERESULT}"!="SUCCESS"]?Playback(im-sorry&an-error-has-occurred&please-try-again-later&goodbye)) [extensions_additional.conf:3266]
5. Hangup() [extensions_additional.conf:3267]
-= 1 extension (5 priorities) in 1 context. =-
[root@freepbx ~]# asterisk -x"dialplan show *3710@from-internal"
[ Included context 'app-callseize' created by 'pbx_config' ]
'_*37.' => 1. Macro(user-callerid,) [extensions_additional.conf:3263]
2. Noop(${CALLERID(num)} is seizing the call from ${EXTEN:3}) [extensions_additional.conf:3264]
3. Bridge(${IMPORT(${CHANNELS(${EXTEN:3})},BRIDGEPEER)}) [extensions_additional.conf:3265]
4. ExecIf($["${BRIDGERESULT}"!="SUCCESS"]?Playback(im-sorry&an-error-has-occurred&please-try-again-later&goodbye)) [extensions_additional.conf:3266]
5. Hangup() [extensions_additional.conf:3267]
-= 1 extension (5 priorities) in 1 context. =-
[root@freepbx ~]# asterisk -x"dialplan show *371011@from-internal"
[ Included context 'app-callseize' created by 'pbx_config' ]
'_*37.' => 1. Macro(user-callerid,) [extensions_additional.conf:3263]
2. Noop(${CALLERID(num)} is seizing the call from ${EXTEN:3}) [extensions_additional.conf:3264]
3. Bridge(${IMPORT(${CHANNELS(${EXTEN:3})},BRIDGEPEER)}) [extensions_additional.conf:3265]
4. ExecIf($["${BRIDGERESULT}"!="SUCCESS"]?Playback(im-sorry&an-error-has-occurred&please-try-again-later&goodbye)) [extensions_additional.conf:3266]
5. Hangup() [extensions_additional.conf:3267]
-= 1 extension (5 priorities) in 1 context. =-
It supports any amount of digits
request to have it disabled by default
https://issues.freepbx.org/browse/FREEPBX-24149
1 Like
That’s not what I asked. I know it can support any extension length. What I asked was has there been any testing done with 2 or 4 digit extension lengths?
If it helps, I have the original code from @PitzKey working in a production environment with 4 digit extensions. I have not tested the Edge implementation though. Not sure if there are any differences between the code.
Core v16.0.68.14 has this disabled by default.
I will try to work on changing the feature code as well as testing with shadow extensions.
I tested this, say you have extension 101 and its shadow extension 99101. In my testing I saw the following:
- If only 99101 is on an active call, dialing *37101 will seize the call from 99101.
- If 101 and 99101 are on active calls, then is when *37101 will fail, as it finds two active channels.
Please let me know if this is what you experienced.
If so, then I am thinking to modify the dialplan to loop through all matching channels it finds and ask you which one you want to grab.
Does that make sense?
Also, as mentioned, *37 is already taken by PMS, it was mentioned that *33 is free, however, I am thinking of using *59 as it doesn’t appear to be used and has less of a chance to interfere with direct dial to voicemail.
How will the user be able to pick the channel and know it is the right channel? Since channels names contain 8 alphanumeric characters there can be chances that dialing *37101 not only will get 101, 99101 but another channel(s) that has 101 in it. At that point too, how does the average user know about shadow extensions? Will the average user know that 99101 and 101 are both same extension? This still doesn’t cover some other scenarios as well. The two I can think of right now are:
-
I, personally, depending on how busy could have at least 2 answered calls going (1 on hold, 1 active). So an extension with multiple active calls on it, which of those bridged calls are you stealing?
-
A single extension but multiple devices/users. There could be three calls to that extension and three different people on each of those calls. Which one is being stolen?
Outside of those things, what has the actual reaction been to this in your testing? How do both the users and the callers react to having an active call stolen? Neither of the parties in the active bridge have no idea this happens until it happens. Either of the parties could be in a middle of a conversation which will be cut off. A user could have a caller on hold and then lose the call. There could be a case of Bob is on the phone with Alice then Dave steals the call from Bob. Bob will just be dumped from the bridge which can give the impression the call has dropped or the other party hung up.
Just curious, but is it acceptable to have a function in FreePBX that can be used for a purpose that doesn’t necessarily make sense for every single call made on FreePBX? In this situation, this solution makes sense for grabbing a call on a public address speaker in a room, but may not make sense if you are in an office and trying to grab a call on a secretaries desk.
100% acceptable and there are some that already exist like this. However, in this particular case that logic hasn’t been determined. Your use case is one of those that this would be a solution for but there are still flaws in the logic as it is right now as channel collision can happen. There are other scenarios that this can work for as long as the logic is there for it.
But for the most part this is not something to be used in most deployments.
I can easily validate if the channel actually belongs to 101. I agree that some channels can have 101 included in the name. I will add that.
That’s why I was thinking of asking the caller if they want to steal the call 8884441234 or 8889994567. Will add that as well.
The above should cover this as well.
Thanks for your input, Tom!
Which is why it comes disabled by default.
Those wouldn’t be part of the channel name, they would be part of the channel variables. So if they are trying to pick a call from/to 8884441234 you will need to check actual channel variables. In the case of an incoming call you would need to check callerid variables, in the case of outbound calls you would have to check connectedline or other variables to make sure you’re getting the call based on either CallerID info or dialed digits info.
This still doesn’t answer how channel selection would happen if there are multiple matching channels. How will the user know which channel is the right channel to select?
As my coworker is fond of saying, “The juice ain’t worth the sqeeze”. Given how much use this feature is likely to get, having it fail silently when the dialed extension has multiple matching channels doesn’t sound like a problem to me.
1 Like
Yeah but you won’t be the one dealing with users telling you they keep trying to use the feature and it doesn’t work. The actual user experience needs to be part of the discussion and logic here.
Tom, have you even looked at how we “steal” the call?
If PJSIP/101 is talking to 8884441234 and PJSIP/99101 is talking to 8889994567, when 102 dials *37101 I can easily find both numbers, playback and ask 102 which number they wish to “steal”.
I will post an updated dialplan that shows how it is done.