Thanks for responding! You guys are one of my favorite companies to deal with in terms of support. I can tell you really want to have a great product.
We were having the issue between 20-50 calls. Had 500, 700, and 1,200 sip phones connected at various points. Some sites (maybe 10-20 sites) had 20 phones with 20 BLF’s all watching one another along with ~2 parks. Most of our phones are set to 300 second registers.
When we first tried we converted 1,200 phones (“converted” a bit less since we had preexisting PJSIP extensions but you get the idea) and had 40-70 active calls soon as it hit 9am.
I can say based on symptoms:
Was the hold music choppy and horrible using the default freepbx hold music
Was the IVR and recording choppy to the point where you could miss words or options, or perhaps the entire recording
Were calls choppy where you miss parts of words or multiple words?
If all of those were happening then it was happening to us. The very first symptom is hold music and recordings getting progressively worse. Call quality issues happen once hold music and recordings get to a certain point.
We were running a live machine with most Freepbx features enabled and users constantly transferring, putting people on hold, and doing what they do. Users are always experts at stress testing
We split our 1,200 phone server between 3 servers. One had 500 phones and the full call flow of the 1,200 server. It would work ok with under 20 calls but I noticed when it got to 20-30 we could hear MOH and recording quality issues. We gave up and had to fix the issue asap so we converted to chan_SIP.
That really shouldn’t be happening with that call load, so I’d suspect something else is going on. Working on another test batch right now, in the mean time would you be willing to try some things on your end? Some things to look at:
Are all of those watchers legitimate, or are there maybe several coming from something like the Polycom phone doing multiple SUBSCRIBEs when it shouldn’t be? 7000 is a lot, and if something changes on that extension, there’s a ton of potential for things to slow down and maybe even result in what you’ve described.
If you are able to set up an environment that replicates this problem, we would definitely be willing to take a look at it. If you’re unable to, perhaps the above is more easy to test?
As far as the Polycoms are concerned, this BLF issue actually might be known. They had a bug in previous versions (I think 5.4 or older).
I picked up a new client last year, they said BLF never worked at their previous carrier and the carrier couldn’t figure out way. I upgraded their Polycoms to 5.7 (current last year) and boom, all their BLF issues went away.
That could be related to this. People tend to forget to keep their phones firmware current.
One more thing I forgot to mention: would it be possible to get the chan_sip configuration you used to bulk change over to PJSIP? Just in case there’s something in the conversion process that’s causing things to go haywire. Would be valuable for our tests as well.
Firmware would be an interesting thing to look at. Definitely worth giving it a shot if this is able to be reproduced.