t46s calls on hold operation

[comstar]

I've been trying to find some information about whether or not the operation of the phone can be changed when a call is on hold on the phones.

For example, when you use the HOLD button on the phone, you cannot simply press a BLF key to call another phone. That call is transferred to that BLF. I do not want to have to press the NEW CALL softkey or the next open line appearance on the phone in order to call another phone when I have a call on hold on the phone. If I place a call on hold on my phone, and I either press a BLF or simply dial another phone number, the phone should utilize another line appearance and place that call. If a call is on hold, I should not be able to transfer it without picking it back up again. We have tested this on multiple platforms and it acts the same way on all platforms. I do not want to change the normal function of the BLF button when it comes to transferring a call because our customers seem to really like the one touch transfer to a BLF function.

I should also note that we have tested this on Polycom phones and it works as explained above. If I place a call on hold on a Polycom phone, I can either just start typing in a new phone number to call or press a BLF key and the call will go out normally WITHOUT pressing NEW CALL or another line appearance.

I'm just trying to see if it's possible to change and if so, what needs to be changed to enable this.

Thanks

[jolouis]

As you have already mentioned you can reconfigure the BLF keys to generate new calls instead of doing transfers. However this is a universal setting, so doing that means pressing the BLF will always generate a new call, whether the current call is on hold or not. (it's a catch 22, changing that option will solve your onhold issue, but will eliminate the "one touch transfer" that you said the customer is very happy with).

As far as I know there is no way to configure the behaviour differently in response to different states of the phone. I can see how that would be useful but don't know how much luck you will have convincing Yealink to implement it, try opening a support ticket maybe and see what they say.

[comstar]

Thank you for the reply. Polycom phones work as explained so I don't see why they wouldn't be able to do it. My thought is, if you put the call on hold and then hit a blf and the call gets transferred, that call isn't on hold. The phone is treating that as an active call which defeats the whole purpose of placing a call on hold. I'll look into submitting a request to Yealink about getting that updated.

[arcommct]

I came to the forums looking for a fix for this very behavior. It's unexpected and contrary to the function of every traditional phone system. If I place a call on hold it's because I don't want to process that call further. If I do I should need to pick it up first.

I'm going to follow advice and open a ticket. I have an irate customer and I can't blame them.

[russavd]

We are having exactly the same problem.

I have several aggravated users that cannot understand why calls on hold get transferred using BLF, and I cannot come up with any rationale why anyone would want this.

They were using 12 year old Linksys phones that handled this correctly, and I'm having difficulty explaining why Yealink cannot fix a defect (and it is a defect not a feature) that even Linksys was able handle over a decade ago.

As a software developer, I know how easy this would be to fix, and if Yealink wants to keep supporting this "feature", just add a config toggle for "Don't transfer calls on hold".

[comstar]

(03-08-2019 06:34 PM)russavd Wrote:  We are having exactly the same problem.

I have several aggravated users that cannot understand why calls on hold get transferred using BLF, and I cannot come up with any rationale why anyone would want this.

They were using 12 year old Linksys phones that handled this correctly, and I'm having difficulty explaining why Yealink cannot fix a defect (and it is a defect not a feature) that even Linksys was able handle over a decade ago.

As a software developer, I know how easy this would be to fix, and if Yealink wants to keep supporting this "feature", just add a config toggle for "Don't transfer calls on hold".

I had a lengthy back and forth with their support and they kept trying to tell me to change the way the blf performs instead of addressing the actual issue of the call isn't really "on hold" but still an active call. They kept harping on the blf aspect until I finally told them forget the blf, that works fine that way that we want it to work. Even if you press HOLD and need to simply call another phone number outside of the system to simply ask someone a question, you have to either hit NEW CALL or another line appearance on the phone in order to make that call. I ended with suggesting the purchase a polycom vvx series phone and seeing how that operates in regards to placing calls on hold because that's how people expect a phone to operate.

[Bezalu]

What really stinks is if you have your parking lots assigned to BLF keys for easy retrieval.
If "CALLER-A" is in a parking lot, and you take a new call from "CALLER-B" and put them on hold, then try pushing the Lot button to speak to "CALLER-A" again, you have now BRIDGED THOSE CALLS and are now not even part of it to explain anything, so those two callers are now talking to each other wondering what is going on!

This is a doozy and have some irate customers worried about HIPAA violations from our experience with this unbelievable "bug".

[Yisroel_MongoTEL]

(09-21-2020 09:30 PM)Bezalu Wrote:  What really stinks is if you have your parking lots assigned to BLF keys for easy retrieval.
If "CALLER-A" is in a parking lot, and you take a new call from "CALLER-B" and put them on hold, then try pushing the Lot button to speak to "CALLER-A" again, you have now BRIDGED THOSE CALLS and are now not even part of it to explain anything, so those two callers are now talking to each other wondering what is going on!

This is a doozy and have some irate customers worried about HIPAA violations from our experience with this unbelievable "bug".

Why aren't you using the Call Park DSS key type instead of a simple BLF Key type?!

It makes perfectly sense that a BLF key should act as a Transfer (I think you can change that behavior for BLFs in general not to act as a transfer).