Windows 16.3.0.144 & Yealink T58, CTI, first digit of number discarded when phone is sleeping

[nobody]

I updated a couple of yealink phones to the currently recommended firmware 58.85.0.5, and at the same time the Windows client was updated.
Now, when I dial using CTI mode the first digit is silently discarded by the phone.
To make a sucessful call I now have to check if the phone is awake then start the call from the windows client. Since uprades have been made at the sime time, I am not sure who is responsible for this problem.
Anyone else experiencing this?

 

[complex1]

Hi,

I do not have this issue with T5xW (xx.85.0.5) and Windows client (16.3.0.144)
I suggest to reset the phone(s) to factory default, re-provisioning and try again.

 

[nobody]

Did this, no change. I meanwhile think this is not a problem of the phone because:
If the numbers starts with a "+nnnn" the number is dialed as 0nnnn, if the number starts with a 0nnnn then it is dialed as 00nnnn (a 0 is added instead of dialing as is).
The Windows Client is configured to replace "+" with "00".
When the phone does not sleep, everyhting is dialed as it should:
0nnnn is dialed as 0nnnn
+nnnn is dialed as 00nnnn
I also uninstalled and reinstalled the Windows Client
I also tried the WebClient, the WebClient works (it uses a different system to talk to the phone) anyway).
I tried the multiline tapi driver.
if the number starts with 012345 the number is dialed as 02345

 

[complex1]

I think you have to check the E164 settings in your PBX.
Settings > E164 Processing

 

[nobody]

I will also check this. But since dialing works 100% correct, when the phone is awake, I assume this will not make it better. E164 processing also will be applied (to my knowledge) only after the phone dials and not before.
I will do a wireshark capture to check what really happens between client and phone.

 

[nobody]

So, I made a wireshark recording.
Reardless of the phone beeing sleeping (display off) or not, the Windows Clients sends a http GET request (containing the correct number) like:

http://admin:[email protected]/servlet?key=;;;;;0;0;4;4;1;2;3;4;5;6;7;8;9;0;ENTER

That would mean the phone has a problem properly receiving the dial command when the display is sleeping. To work around this, the Client could send:

http://admin:[email protected]/servlet?key=BACK_IDLE

to the phone, and then send the dial string.

But what puzzles me, is that the yealink documentation regarding the syntax of the dial string is different. Instead, the Documentation says, to dial a number the client should send:

http://admin:[email protected]/servlet?key=number=00441234567890

If I try this, it works perfect, regardless if the phone is sleeping or not, and, in contrast to the way 3cx dials, which always is problematic (phone emits unnecessary dtmf beeps, the dialing process is dead slow and will not work if the phone is on a different screen then the main screen) this works silent and always perfect.

Why doesnt use 3cx the dial syntax of the phones manual? It is simpler and works much better?

 

[complex1]

I assume you are running 3CX v16 update 5 on Debian 9, Windows 10, Server 2016 or 2019?

 

[nobody]

Server 2016, Version is 16.0.612. Currently no updates availiable.

 

[complex1]

I'm lost, sorry.
Maybe 3CX or someone else can help you further.

 

[nobody]

Thank you for trying to help.

I found out a little more:
If you look in the file where the cti provisioning is done:

C:\ProgramData\3CX\Instance1\Data\Http\Interface\MyPhone\cti_template.xml

Then goto the Entry where the yealink phones are handled
You find the command which is used to dial.
I replaced it with the "correct" (from the yealink manual) command so now it says:

    <option value="make_call">http://%%deskphone_useraccount%%:%%deskphone_password%%@%%desktopphone_ipaddress%%/servlet?key=number=%%dialled_number%%</option>

But still dialling does not work correct. I made a wireshark dump again, and noticed the program sends a ";" after every number.
In the xml description indeed is a line:

<cticommands delim=";">

I removed the ";" and everything works fine ATM.

I am asking myself why 3cx inserts a ";" after every byte sent to the phone, when (on first sight) this is not necessary and also breaks things in the current yealink Firmware?

 

[JohnS_3CX]

Hi,

We have already notified Yealink regarding this, and they replied that it will be fixed in a future firmware revision.

 

[nobody]

Thank you John,
but, why does the template uses the ";" as separator for every digit? Without the ";", dialling works perfect, and it is fast and the phone does not emit unwanted sounds while dialling?

 

[JohnS_3CX]

That is also a valid method as defined by the Yealink guide for Action URLs, so the phone should still accept this method.

 

[nobody]

I understand, but the other method without the ";" after every digit works so much better, why dont you use this?
Again the advantages:
No sound emissions while the number is dialed (there are complaints about this problem already)
Works more reliable (from my first impression) because dialling will be done regadless what menu or screen the phone currently is displaying
Dials the number instantly, like if you dial using csta, no waiting
Easy to implement (besides testing) becaus no code has to be changed only the entry in the
cti_template.xml has to be modified

 

[JohnS_3CX]

Yes, I see what you are saying, and it would be easy to implement from a single person's point of view.

However, since we support many Yealink models across many firmware generations, it would require regression testing across all Yealink models that support CTI, it would need debugging since things will need to change under the hood from both the template parsing mechanism and the Windows client, and and it would require extra work done for something that already works and is not currently causing any issues.

The problem is clearly with the firmware of the specific model that does not comply with the original Yealink specifications due to a small bug that has been scheduled to be fixed, so it does not make much sense to go into all the above trouble for a single device that is scheduled to be corrected anyway and risk breaking a mechanism that already works for the rest of the existing Yealink line.

 

[nobody]

Understood. Thank you.
Maybe, If you have moment with free capacities, think about implementing this. Because the current way it works is far from perfect. I will do my very own testing in the meantime withT58, T48, T42 and T46.