Delayed Dialing Yealink - Remote Phones

[ucme4now]

Been wrestling with a problem with a hosted customer who has Yealink T28 & T38 phones and a new T52S. When the customer does an intercom dial "*0 + Extension" from the T2/T3 series to the new T52S, there is a noticeable delay of 8 - 10 seconds before the T52S picks up. The same delay is experienced when making a PSTN call. I did wire-sharks from the management console of both working and non-working calls and you can clearly see the delay from the INVITE to the RTP arriving on the intercom call.

Read multiple similar posts but no resolution that matches my configuration. Multiple data points for clarity:

1. Using "Direct SIP (STUN-remote)" for provisioning to the T52S, behind SBC (not 3CX).
2. Manual provisioning for the T28/T38 phones.
3. SBC is an Edgewater 2900E, (works well).
4. BLFs are key for this client (light them up!).

This is not a firewall issue as the T52S responds accordingly to the provisioning requests, etc. No audio issues, no BLF issues, just the delayed dialing. This is not the inter-digit dialing delay either. After plowing through other similar instances, the one common factor was the legacy phones are NOT using STUN for provisioning and the T52S is. I disabled NAT on the "Account" (account.X.nat.nat_traversal) page [on the T52S] and everything began working as expected, no dialing delay between the T2/T3 or PSTN.

Now the issue was to modify the phone template and push out to the phone. So here is where it gets tricky...
When you look at the phone template there are multiple sections, one is specific to REMOTE STUN provisioning. I changed the parameter "account.1.nat.nat_traversal = 0" to zero (0) from one (1), this shuts off/disables STUN for this option.

{IF network=REMOTESTUN}
#Enable or disable the NAT traversal; 0-Disabled (default), 1-STUN;
account.1.nat.nat_traversal = 0

So far no adverse affects and the result is no delay. The key for all of this was to ensure that IF this parameter was disabled, I would still be able to remotely provision the phone. I did multiple tests to ensure that I still had the ability to remotely provision the T52S and I do.

All of this assumes you know and understand how to modify the phone template. It is 12,000 plus lines long with multiple sections. Read the Yealink docs before doing anything... they are readily available.

Hope this helps someone else.

 

[cobaltit]

Any chance this customer is on AT&T DSL? I was just testing a setup with a remote soft phone that had that same delay with direct SIP that went away when I forced the tunnel which points to a firewall/ISP induced delay.

 

[ucme4now]

Negative. In the heart of NYC with oodles of bandwidth over fiber.

 

[cobaltit]

So setting the phone to LOCAL LAN should do the trick without having to edit the template. And setting it to LOCAL LAN will not stop you from provisioning the phone remotely.

 

[ucme4now]

Negative. Only if you are using the 3CX SBC you can remotely provision. I do not use the 3CX SBC for a lot reasons, mainly a managed solution with tools to support my customers. I just tested to verify and no lunch today. Remote provisioning Yealink phones through EdgeWater 2900 series SBC works like a champ. No reason to leave the office now....

 

[cobaltit]

I guess I'm not sure what you mean by remotely provision but I was speaking from a strict technical sense that selecting a provisioning method (LOCAL LAN, STUN, SBC) does not prevent a phone from being able to pull the configuration from 3CX. So you could provision the phone as LOCAL LAN and then setup Option 66 on the local DHCP device to hand out the provisioning URL. You could also use the Yealink RPS server directly to point the phone to your 3CX install. Or if you manage the edge device you can poke a hole or VPN access the remote subnet and put the provisioning URL into the phone. All meet my definition of remote provision if remote means you don't leave the office.