Solved Very slow Park BLF operation on site

[datamerge]

Hi All

We have a site with 40 handsets. 20 are local to the 3CX and 10 are at a remote site. Every handset has 4 shared park BLFs. When we park a call with the BLF, it can take 10 seconds for the light to go from flashing red, to solid red and then for the handset to hang up. Retrieving a call from Park is similar. It can take 15 to 20 seconds for the call to connect and even longer for the park light to go green.

Is this an issue due to a large number (40) handsets monitoring the BLFs? Is 40 too many? The latency to the remote site is about 5ms and there is about 1Mbit dedicated to the SIP traffic. Could this be the issue?

I have not done any SIP tracing as yet. I thought I would just throw it out there to see if anyone else has found limits in the number of BLFs that can reasonably be expected to work efficiently on a system.

To the 3CX engineers: How many concurrent SIP transactions can the PBX handle and do you have any idea of the message rate the PBX can handle? E.G. How many SIP transactions per second...roughly?

 

[eddv123]

On premise should not be too much of an issue I don't think however please provide further details on your remote BLF's - these can be a problem especially if running your remote extensions using the STUN/RPS method.

If using across the SBC however you can have up to 50 extensions and 250 BLF's are the max across an SBC (running Windows or Linux not the Raspi version which is considerably less).

FYI if you do start tracing using Wireshark BLF uses the SUBSCRIBE and NOTIFY methods.

 

[datamerge]

Thanks Eddy.

Yes I know how it works. Very chatty is SIP with a NOTIFY going to all BLF monitoring devices, individually, for every stage of a monitored call.

The network is quite simple with a VPN between sites. All handsets directly accessing the PBX with clean routing and no NAT. So no issues with SBC, no Stun, etc. I have this nagging feeling that there is a network issue on the site, which is under our responsibility anyway. The other worrying thing was complaints of choppy voice within the LAN which never happens when I test of course. It does make me suspicious. I haven't put park on my other larger sites and maybe it wasn't such a good idea.

I just wanted to get some anecdotal evidence before I go down the rabbit hole with this one.

 

[eddv123]

A VPN tunnel is an even better option than the SBC (but not used as widely) so you should not experience quite as many issues as using the latter methods.

 

[datamerge]

OK. An update.

It looks like this was a handset firmware issues. Handsets are HTEK UM924s. They were on 2.0.4.4.41. Upgraded to 2.0.4.4.50 which has just gone official with 3CX and the problem appears to be resolved.

 

[YiannisH_3CX]

Glad to see the issue has been resolved and thank you for updating the thread with your solution.