Yealink T46s Park button

[mhessels]

I have a client that wants to know which parking lot their call was parked on. When I setup a BLF key to Park the call using the Park function it calls out the number, which is good, but the button stays red and occupied. This doesn't allow anyone else in the building to use the Park button.

Is there anyway around this?

[BobBluePackets]

What PBX are you using with your Yealink??

Regards

Bob

[mhessels]

(01-24-2019 09:31 PM)BobBluePackets Wrote:  What PBX are you using with your Yealink??

Regards

Bob

I'm using FreePBX Version 14

[BobBluePackets]

Same here...FreePBX with all recent yealink models

In the middle of work at the moment, but will post something in the next few hours.

Regards

Bob

[BobBluePackets]

If you use a single line key on the Yealink (e.g. no expansion console), you should use the line key with
Transfer as the type, Label of Park and 70 as your value (assuming that you have stayed with the standard parking lot of 70.

This has worked for quite a while with no issues across a number of FreePBX versions.

If you have an expansion console, you also have the can also setup several line keys on here to park it directly onto a Parking Slot e.g. drop the call onto 71 or 72 or etc....and the LED show red to indicate a parked call on that slot (or show the slot it is parked on when using the park 70 key.

Is this not working for you???

Regards

Bob

[jolouis]

What Bob has mentioned is entirely true. Rather than dedicating a bunch of BLF buttons though for Yealink phones we typically implement a very simple XML script that can pull the call park info directly from Asterisk. Doing this, the call park button is setup as a transfer to 70, and then a second button is setup as XML browser to our script.

When the user hits the XML browser our script does a simple "asterisk -rx parkedcalls show", parses the output and formats it for Yealink "YealinkIPPhoneDirectory" XML list. That way any user gets to see not just parked calls, but actual info about them (i.e. what phone number is parked where), on demand, and can pickup any call simply by selecting it within the XML view. It's pretty slick and had made many of the old "key" customers comfortable making the switch to a proper PBX.

[mhessels]

(01-28-2019 10:08 AM)BobBluePackets Wrote:  If you use a single line key on the Yealink (e.g. no expansion console), you should use the line key with
Transfer as the type, Label of Park and 70 as your value (assuming that you have stayed with the standard parking lot of 70.

This has worked for quite a while with no issues across a number of FreePBX versions.

If you have an expansion console, you also have the can also setup several line keys on here to park it directly onto a Parking Slot e.g. drop the call onto 71 or 72 or etc....and the LED show red to indicate a parked call on that slot (or show the slot it is parked on when using the park 70 key.

Is this not working for you???

Regards

Bob

Hey Bob

That is the way I am doing it right now. The only thing feature that is missing is the parking lot number is not announced or shown in any way. I have one or two clients that are constantly on the phone and if they don't pay attention to the red lights on the phone they forget which parking lot their call is on.

---

(01-28-2019 03:50 PM)jolouis Wrote:  What Bob has mentioned is entirely true. Rather than dedicating a bunch of BLF buttons though for Yealink phones we typically implement a very simple XML script that can pull the call park info directly from Asterisk. Doing this, the call park button is setup as a transfer to 70, and then a second button is setup as XML browser to our script.

When the user hits the XML browser our script does a simple "asterisk -rx parkedcalls show", parses the output and formats it for Yealink "YealinkIPPhoneDirectory" XML list. That way any user gets to see not just parked calls, but actual info about them (i.e. what phone number is parked where), on demand, and can pickup any call simply by selecting it within the XML view. It's pretty slick and had made many of the old "key" customers comfortable making the switch to a proper PBX.

Hey Jolouis

This sounds awesome. Is there somewhere to access an example of this script? I have quite a bit of programming knowledge but I've never tried to put a script together for Yealink phones.

[jolouis]

(01-28-2019 09:40 PM)mhessels Wrote:  This sounds awesome. Is there somewhere to access an example of this script? I have quite a bit of programming knowledge but I've never tried to put a script together for Yealink phones.

I will check with my manager and see if we can release the code without too much hassle (we developed it internally so there may be licensing issues). That said if you're a coder it's not exactly rocket science. Key things:
1) XML developers guide from Yealink is available here In there, look for the example definition of YealinkIPPhoneDirectory.
2) As I said before all you need to do is run "asterisk -rx parkedcalls show" from your script on the server. Asterisk will spit out a table that shows you the parking lot number along with the channel. The format varies a little depending on what version of Asterisk you're running but the information is the same.
3) Once you get that output, parse/filter through it. Each entry will have a channel identifier. (Something like "SIP/xxx-00003424" etc). For each of those, you can call "asterisk -rx core show channel SIP/xxx-0003424" or whatever the identifier is, and all the info you could ever want should get thrown back. Once again, parse it up, then use both pieces of information to populate your YealinkIPPhoneDirectory.

[BobBluePackets]

MHessels,

One other item that may assist with hearing the extension
Under Features / Transfer the following setting should be used
Transfer Mode via Dsskey - : Attended transfer
(however impact on other ways you might be doing transfers (e.g. whether you use single button transfers etc), so you should test after changing the transfer method.

It would be really good if Yealink could add some code to either
1) Allow change in transfer mode per DSS button (e.g. you don't want attended transfer when transferring to a conference)
2) or allow at least a change the transfer method per main console and Expansion console

However I am intrigued by the solution that Jolouis has come up with, which sounds like a great and more business like solution.

Jolouis, if you can provide an example, this would be appreciated, otherwise thanks for the rough outline of what you have done...might have a play on the Weekend.

Regards

Bob