Yealink Forums
Call Parking, can we get this fixed please!?!? - Printable Version

+- Yealink Forums (http://forum.yealink.com/forum)
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: General topics (/forumdisplay.php?fid=15)
+--- Thread: Call Parking, can we get this fixed please!?!? (/showthread.php?tid=10536)



Call Parking, can we get this fixed please!?!? - jayg30 - 10-07-2015 11:40 PM

The issue is pretty simple and reproducible. I've experienced it on all firmware versions for the past 2 years for all phones I've tried (T2x and T4x models). I am willing to bet it behaves this way for ALL Yealink phones. Other phones handle this differently/correctly.

Setup the "Call Park" DSS key as described in any Yealink phone manual.
Test Call Parking;
  • Caller A dials Caller B
  • Caller B presses "Call Park" DSS key
  • Caller A is placed in the parking lot
  • Caller B is disconnected
  • Caller B never hears the parking lot slot

Everything is correct EXCEPT the last point (Caller B never hears the parking lot slot). For most people hearing the slot number is important. It appears as if the Dss Key is set to type "Call Park" on Yealink phones, it utilizes a blind transfer instead of attended transfer. Even if the "default transfer via Dsskey" is set to "attended transfer" it makes no difference.

So I assume the key type for Call Park must be hardcoded to complete using a blind transfer (feature code ##) instead of attended transfer (*2).

I would propose the default method change to attended transfer for Dss Key type "Call Park" so the person parking the call is announced the parking lot #. I'd also suggest creating an option to change this behavior between the two options (ie. feature option, "announce parking lot?: Yes/No).

The only workaround for this currently, that is not ideal, is to NOT use the call park key type at all. Instead to use set the Dss Key Type to transfer, and set the value to 70 (or whatever your parking lot is), and finally set the "transfer mode via dsskey" to attended transfer. This is not ideal because it imposes the restriction on "transfer mode via dsskey" just so call parking works correctly. It also requires more button presses. And finally (the biggest issue) it doesn't hang up the transferred calls and instead you end up with two active calls on your phone (the original call you are trying to park and the parking lot call which is playing MoH back to you) and you have to make sure to hang up these calls.

Testing on a up to date FreePBX system. This is an issue that has existed for a while from my understanding. See HERE.


RE: Call Parking, can we get this fixed please!?!? - CWR - 10-07-2015 11:59 PM

I think this needs to be a new type of park for your specific PBX.

3cx uses Shared Parking Spots - and we dedicate a key to each. SP1, SP2, SP3.
We know where we are parking the call and the light turns red. So, no need for feedback from the system.

(It also has the type of parking you are referring to. This may be helpful to those users.)


RE: Call Parking, can we get this fixed please!?!? - jayg30 - 10-08-2015 12:13 AM

(10-07-2015 11:59 PM)craigreilly Wrote:  I think this needs to be a new type of park for your specific PBX.

3cx uses Shared Parking Spots - and we dedicate a key to each. SP1, SP2, SP3.
We know where we are parking the call and the light turns red. So, no need for feedback from the system.

(It also has the type of parking you are referring to. This may be helpful to those users.)

FreePBX can do the same exact thing. You can also tell it what slot to park the call in. This doesn't help or address the issue though.

What do you do when you have a large volume system that utilizes parking lots? Say you have a parking lot with 20, 30, 40, even 50 slots that all get used heavily, are you going to dedicate BLF keys to monitor all those lots? What about if the phone doesn't have a lot of BLF keys (T22/23, T41/42, etc.)?

This is why the parking lot feature is setup to announce the parking lot it selects. It allows you to park the call in the next available slot without having to have BLF keys to monitor/know where they are parked. This is pretty much required in a large system IMO.

IMO the only thing that could save this behavior on Yealink phones is the use of the FreePBX Phone Apps that allow you to pull up a list of parked calls to visually see. Still doesn't solve the underlying issue though.

And again, this is something that DOES work (and has for years) on other brands of phones with FreePBX/Asterisk.

I might be wrong about it using blind/attended transfer, but the issue is real.

If you setup the key type on the Yealink phone to DTMF and set the value as ##70# it works (call is parked, lot is announced, call(s) are disconnected).
## is "in-call Asterisk Unattended Transfer"
70 is the parking lot extension
# is the send key

It also works with DTMF *270#, expect you remain on the transfer in the parking lot because it is an "attended transfer".
*2 is "in-call Asterisk Attended Transfer"
70 is parking lot extension
# is send key

This doesn't address the lack of correct functionality of the BUILT IN call parking key type of the yealink phones. It also has it's own side effects like the person parking the call having to listen to DTMF key presses. It would still be best to have the Call Parking key type to announce the lot #.


RE: Call Parking, can we get this fixed please!?!? - CWR - 10-08-2015 02:22 AM

I don't disagree with your need - just don't change the existing behavior. Add an option or a new "Monitored Call Park" BLF Type.


RE: Call Parking, can we get this fixed please!?!? - keffa - 10-09-2015 05:30 AM

Yes, this is a very real issue.

This is an interesting issue for me because I have never seen the "Call park" DSSkey option actually work correctly under any Asterisk configuration. We utilise the Transfer or DTMF method as described in previous posts to work around it.

It appears that the "Call park" option is simply a blind transfer, all it does is change the icon on the T4X models and gives it a mysterious red X that doesn't seem to have any reference to what the feature does. What really confuses me is what setting on the server is the phone looking for that defines whether or not it gets the red X through the icon?

It actually serves a handy purpose though sometimes. If you have your phones set to do attended transfers by default in the settings, the DSS keys will always do attended transfer, but you can use the call park button as a sort of override button to do a blind transfer to a number, allowing you to mix and match transfer methods via the BLF buttons without having to resort to DTMF. Completely against design and ugly as hell of course but until Yealink give us the option to select the transfer method per DSSkey as well as the default method, it will have to do.


RE: Call Parking, can we get this fixed please!?!? - James_Yealink - 10-09-2015 04:00 PM

Hello,

When you press "Call Park" DSSKey phone will do a transfer. Once phone receive a NOTIFY message(carrying 200OK in body header) from server it will go back to idle status thinking the transfer is successful.

There is an provision parameter which can change the behavior:
transfer.hang_up_after_success_trans = 0

If you set the parameter to 0, phone won't go back to idle and can receive RTP packet. But it needs PBX server to send a BYE message to end the call, or phone can't back to idle itself.

Regards,
James


RE: Call Parking, can we get this fixed please!?!? - alexgonzalez - 10-12-2015 12:18 AM

Hello,

This is what I have found and would like, using elastix freepbx, on T46G system and latest firmware T46-28.80.0.70

Using the DSSKEY
Set Type Value Label Comments / Issues
Transfer 70 Park Call works, but requires you to either hang-up to complete it or hit Transfer to hang up. Requires more steps before you can intercom someone to see if they want the call or for screening purposes or paging someone.

Call Park 70 Park Call doesn't work correctly. The first time you take a callers call and press this, it announces the parking location to the caller instead of you the phone user? BUG! If you pickup the parked call, and park them again, then it works correctly, it announces the parking location to you, then hangs up immediately. You can continue to this and works fine after the first time. This needs to be fixed!

DTMF ##70 Park Call works, but very annoying and slow, you have hear tones first, then starts to say "transferring" but gets cut off and then you hear the parking location, then disengages your phone. Very slow process this way.


Want to use the HOLD key to be re-programmed to a good Call Park function that fully works.
why?
1) This helps in many ways, allows user to have only one way to put callers on "hold".
2) Problems with Hold, it plays the local phones hold music, instead of the system hold music.
3) you can't use your phone to intercom, page or call someone else while your phone is in on Hold.
4) allows you to do this on any phone that has the HOLD button, which is mostly all of them
5) frees up a DSS key, and makes better use of the HOLD key that is currently worthless in business, small to large environments
6) allows you access to do the Call Park regardless of where your page screen is at. Now you have to page back to the "park call" page on the T46G if you are not on that page.

If yealink would fix the Call Park functions and allow you to softpatch what the HOLD button does while you are talking/on the phone call, I think it would then be a workable situation. They are suppose to already have the softpatching of what Hold button does per other thread in V80, but it has not been implemented yet from what I can see. 28.80.0.70

Thanks, and hope to hear if anyone else has any ideas.

Alex


RE: Call Parking, can we get this fixed please!?!? - alexgonzalez - 10-12-2015 01:40 AM

Hi,
Totally agree, this is big problem and needs resolution, been going on for far too long and training reception desk is very difficult as its not intuitive enough, too many keys strokes.

The call park function, does not announce the parking location the first time you park that caller, it actually announces it to them instead of the phone user? However, if you pickup that parked call and park it again, then it works right. Parks the caller again, announces to user and hangs up the phone. Like it should. Very strange, why doesn't it work from the get go?

Frustrated, installer and user!
Alex

(10-09-2015 04:00 PM)Yealink_James Wrote:  Hello,

When you press "Call Park" DSSKey phone will do a transfer. Once phone receive a NOTIFY message(carrying 200OK in body header) from server it will go back to idle status thinking the transfer is successful.

There is an provision parameter which can change the behavior:
transfer.hang_up_after_success_trans = 0

If you set the parameter to 0, phone won't go back to idle and can receive RTP packet. But it needs PBX server to send a BYE message to end the call, or phone can't back to idle itself.

Regards,
James


James, where and how can I try to put this provision parameter, I have never gone to code before, just use Elastix and the PHone GUI.
Alex


RE: Call Parking, can we get this fixed please!?!? - alexgonzalez - 11-02-2015 03:53 AM

(10-12-2015 01:40 AM)alexgonzalez Wrote:  Hi,
Totally agree, this is big problem and needs resolution, been going on for far too long and training reception desk is very difficult as its not intuitive enough, too many keys strokes.

The call park function, does not announce the parking location the first time you park that caller, it actually announces it to them instead of the phone user? However, if you pickup that parked call and park it again, then it works right. Parks the caller again, announces to user and hangs up the phone. Like it should. Very strange, why doesn't it work from the get go?

Frustrated, installer and user!
Alex

(10-09-2015 04:00 PM)Yealink_James Wrote:  Hello,

When you press "Call Park" DSSKey phone will do a transfer. Once phone receive a NOTIFY message(carrying 200OK in body header) from server it will go back to idle status thinking the transfer is successful.

There is an provision parameter which can change the behavior:
transfer.hang_up_after_success_trans = 0

If you set the parameter to 0, phone won't go back to idle and can receive RTP packet. But it needs PBX server to send a BYE message to end the call, or phone can't back to idle itself.

Regards,
James


James, where and how can I try to put this provision parameter, I have never gone to code before, just use Elastix and the PHone GUI.
Alex


James, I don't understand why the Call park feature doesn't work the first time, but then works after you try it the second time, and third, etc on the same call. The initial call, when you press the programmed BLF key with call park, why doesn't it do what it is supposed from the beginning. Why would it not work the first time, but then work any proceeding times afterwards if the server was not sending the correct things?

Here is sequence:
>Caller calls in. User answers phone.
>User presses key programmed on BLF key as Call Park.
>Call park puts caller on hold, and announces to the CALLER the parking location? instead of to the user?
>Still same call, pickup the call from the parking location.
>Put the same caller on Call park again, same way by pressing the programmed BLF key as Call Park.
>Now works correctly, puts caller on hold, and announces to the phone user where the call was parked.
>From here on out on this call, you can park and unpark and it works correctly.
>New call comes in, and user answers. starts all over again, you can't park them properly the first time. It does park them, but announces to the caller the parking location again.

Why does it EVER need to announce to the CALLER the parking location. Why after the first time, does it then begin to work correctly?

I need to get this fixed, so that the call park BLF key works correctly from the get go. Is there an email address i can send you this issue directly so you can help me determine if this is a system issue or phone issue. I need help to solve this.

Thanks,
Alex Gonzalez


RE: Call Parking, can we get this fixed please!?!? - alexgonzalez - 11-13-2015 12:47 PM

James or someone in support, can I get a reply please?
Alex