Directed call pickup on BLF

Status
Not open for further replies.

rdaeseleer

Platinum Partner
Advanced Certified
Joined
Oct 24, 2019
Messages
32
Reaction score
11
Hi,

I have come across some setting in 3CX in combination with Yealink phones that I find not very straight forward. I'll try to explain in my best English.

In 3CX you have the ability to pickup a call from another extension with dial code *20*(default). This will route the longest waiting call present on the 3CX PBX to you. Ofcourse all settings and rights need to be correctly set for this. Let's presume for now that this is the case. To pickup a call specific to an extention you can use this dial code followed by the extensionnumber. This works as it supposed to work.

Now for my 'problem';
When I set a BLF field on a Yealink phone for my colleague I have the ability to pickup calls (to him) via this button. The 'problem' I now experience is that 3CX configures this button with only the pickup dial code set in 3CX(*20* default).
If another call to another colleague, from which I also have the rights to pickup, is made earlier I get that other call rerouted to me instead of the call being made to my collegue under the BLF.
This I find strange behaviour, since I want to pickup the colleagues call that is under the BLF button.
So in my opinion, 3CX should set the field 'linekey.2.extension =' to *20*<extension> instead of just *20*.

Is there a reason 3CX populates this field with just *20*? Or is this perhaps adjustable in management console?

Best regards,
Randy Daeseleer
Technica Groep
 
Hi Randy.

Specifically for BLF-type keys, the phone should in fact dial *20*<extension> if everything was provisioned as expected.

Here is what it looks like when i pickup the call of extension 000 which was ringing on my system:
1637240339249.png


And my default config appears this way as intended:
1637240599259.png

So I'm left wondering why yours would be different, provided you were not using custom templates, or outdated software and firmware.
 
Hi John,

I tested it again and did a capture. I can see in my capture that my phone uses **@ instead of **<extensionnumber> (we use ** for pickup)
cap_LI.jpg
Our 3CX PBX is on version 18.0.237.
The phone, Yealink T53, is on version 96.86.188.1(official Lydis latest Dutch version).
We are not using custom templates.

Are there any other settings I can check?

Best regards,
Randy
 
Hi Randy,

Firstly let's see what the current config gives you. Go to Phones, select a phone, and press the +Config button on top.

Click inside the config window, then search for the "Configure line key" part like the previous screenshot above, and compare it to mine. Is it the same?

If the pickup is wrong, check your 3CX System Settings, then Dial Codes - this is where the Yealink will get it from during provisioning:

1637245708924.png

If needed, correct this like mine above, and reprovision the phones then test one more time please and let me know if the problem is fixed.
 
Hi John,

Underneath the config which our phones get from our PBX.

linekey.3.line = 1
linekey.3.value = 136
linekey.3.pickup_value = **
linekey.3.type = 16
linekey.3.label = Randy Daeseleer
linekey.3.extension = **

It looks like yours, apart from the fact we use ** instead of *20*. We have set this dial code on our PBX.
1637246657922.png
Please advice.

Best regards,
Randy
 
I tried switching my pickup code to ** so I can replicate your environment.

My T53 seems to perform the pickup correctly again
1637246690621.png

So assuming your config files are correct:
1637246758015.png
..then there is no doubt your T53 should have behaved like mine did.

This leaves us with one main difference: the firmware is not the same.
Unfortunately we do not test the Lydis firmware, this is out of our scope.
I can't say for sure that this is the problem, but given our now identical configuration, I would suspect that the different behavior might have something to do with the firmware difference.

You should inform Lydis about this, they might be able to provide some help in this case or at least they might be able to confirm that this only happens with that version of the firmware. Perhaps it is an already documented bug?
 
Hi John,

Thx, I will test with international firmware to see if that makes a difference and will post the result here.

Randy
 
  • Like
Reactions: JohnS_3CX
Status
Not open for further replies.

Members Online Now

Forum statistics

Threads
111,832
Messages
589,278
Members
164,662
Latest member
DejanMDS