Yealink Park BLF's not showing in use

[dig1234]

We have t41p's setup as Remote STUN extensions they work great but the BLF Park lights do not show when park is in use. We can place calls on park and and pickup parked calls but the green lights don't change to red.

Anyone have success getting BLF's to work on Yealink Remote STUN extensions?


Thanks!

 

[lneblett]

Are you running the latest firmware on the phones as pushed by the 3CX system? Is it just for Park or do the BLF lights not indicate for a true BFL condition?

 

[dig1234]

Yes latest firmware. I just tried with a regular BLF and same behavior. Please help!

 

[lneblett]

A few questions:

1. What version are you running and have you done the appropriate port forwarding (which ports?) in the router where 3CX resides?
2. Is there a reason for running STUN? If you have a fixed IP at 3CX's side, and the router is correct, then you can likely do without STUN.
3. How many remote devices are there and are they located together or at different locations?

 

[dig1234]

Thanks for your reply!
We are on 14 sp3. The extensions are at remote sites as remote STUN extensions with TLS. Yes I have port 5060 and 5061 and 5000/5001 forwarded to 3CX. Router is Sonicwall and I have 1to1 nat setup on a separate public IP to avoid the port translation issue.

All our IP's are static so you are correct that STUN should not be required. In fact I had it working without STUN. The reason for STUN is that without it I found that when rapid calls come in succession, one of them would not connect. When STUN is enabled this issue totally goes away. It seems 3cx loses track of the phone's correct IP without STUN. I can see in the logs where the NAT-ALG checks are having problems for rapid calls. So long as the calls come in slowly, 3cx correctly translates the phone's local IP into the "Received IP" of the phone. But in the case of rapid calls the first 1 or 2 calls connect properly but then the 3rd will show the 3cx server's local IP as the "Received IP" in the NAT-ALG checks. Seems like a bug in 3cx but we don't pay for support so I can't report it...
That's the only reason I had to enable STUN.

Getting back to BLF's when I was running without STUN the BLF's have an issue as well. They work for a while then stop working until the phone is rebooted.

 

[lneblett]

Can you tell if the SIP notify is being sent from 3CX to the IP addresses of the remote phones? A wireskark capture on the system running 3CX should show this. If 3CX is sending, then we can look elsewhere.

Were the remote phones provisioned by 3CX and what version firmware is installed on the phones?

 

[dig1234]

Great idea! Problem is TLS makes that difficult, I have had success with the wireshark's decryption but it's very finicky. I will try..

The phones are provisioned off the 3cx server. Firmware version is 36.80.0.95

 

[lneblett]

If possible, you might try and see if running without TLS produces any better results. While the desire is to use TLS, it could be that running "straight" will allow the capture and if the same scenario repeats, and the capture shows an issue, then it seems likely that it would affect the TLS side of things as well. If on the other hand, all is well, then back to trying to pinpoint if 3CX or something in between or the phones themselves. I am guessing that you likely have the same phones internally and that all is well, which tends to rule out the phones.

Another thought is whether or not you can use the 3CX softphone client for Windows and/or one of the cell phone clients set to the same extension and see if they also follow the pattern or end up working correctly.

I have not had a need to use wireshark with TLS but perhaps the following link adds some insight:
http://wiki.snom.com/FAQ/How_to_decode_ ... _wireshark

 

[dig1234]

I followed your advise and turned off TLS and low and behold the BLF's work perfectly. That was the only change I made, simply changing the transport from TLS to UDP made them work. Same STUN, same routers etc. I'm wondering if the TLS code in 3cx requires more testing.

I'm not sure where to go from here..

 

[lneblett]

The only thing I can suggest is to monitor it for a while and see if over time the BLF continues to work correctly. If it does, then put a phone on the same LAN as 3CX and turn TLS back on and see if the local phone shows the issue. If so, then it tends to rule out any network possibilities. If the local phone exhibits the problem, then install the 3CX softphone and compare. if the softphone and the hardphone both show the issue, then it tends to indicate a 3CX issue.

 

[lneblett]

Well, I found this article which is pretty recent (updated last month). Not sure if it helps.
http://www.3cx.com/blog/voip-howto/secure-sip/

Also, with regard to the above, they appear to be using an older version of the softphone client. When you change the transport to TLS, there is no place to enter the cert as they indicate. I assume that perhaps it may now come in the provisioning file.

I also noticed that if you look at the extension settings within 3CX(v14 SP3) using the "other" tab, you will see the TLS setting. What is interesting is that it states: "Currently secure SIP works only for the 3CXPhone for WIndows and MAC clients".

Not sure how one plays against the other and I guess if the latter is true, then it could pose a problem if the need is for both a hard phone and a soft phone on the same extension.

 

[NickD_3CX]

I just tried this on using a T46 (the closest thing I had available) that was connected Remote STUN using SIP TLS ans tested the Shared Parking and BLFs and they seemed to behave as they should.

I believe the best next steps at this point is what lneblett said, run a capture on the phones (Yealinks can to this) then use the Cert to decode the SIP traffic, I know its a bit tricky but that should tell you if the phone received the NOTIFY message or not, confirmed though, the BLF statuses worked for me.

 

[lneblett]

I got a clarification on the TLS statement. It is meant to indicate that if using one of the 3CX softphone offerings, TLS is only usable on the MAC and Windows versions of same.

 

[telin]

I just got the same issue on t40P.
Though, all of our phones are set to UDP.