Darren Schreiber

This is mostly correct. It wasn't about revenue, though. It was about controlling the features of the phone reliably from both the web interface and the phone itself - something that's impossible to do if the phones use the same registration. For example if someone enables call forwarding in their NY office to their cell while traveling to their SF office, then gets to SF, realizes they want to disable call forwarding, but it was set on their NY phone, now there's no way to do that if it's on the phone locally. But they'll still call support demanding we fix it (which we really can't, at least not without server-side sync which is model-specific and complex to build). So we decided early on not to do this.

I would make sure you are on latest 4.3.x kazoo-kamailio-configs altogether. There was an exploit in the wild causing these crashes which we patched some time ago.

What Kamailio version though?

This sounds like a very old bug in an old version of Kamailio. We haven't had this in a long time. What is the version number?

Nothing has been reversed if that's what you mean. There may be waiting pull requests not accepted yet.

I would hang on to those changes, or you can submit them, but we have to break up all the apps into individual repos anyway because that's how the app exchange works, so it may require some work to backport once we've got everything the way we want it. (Also, to be clear, I don't know what you mean by 5.0 branches - we've only had master which was 5.x)

No, it's not closed source. But we have paused on the public stuff to try and finish our app exchange. We are 10 years into this company and the entire point of the company was the app exchange, and it's still not done, so we're finishing that before we finalize and release 5.x

Greetings! We discussed this on last month's business partner call actually - I believe there's a recording of it floating around. But, no, not yet - but will be enabled next week or the week after. Look for an announcement! It's almost there.

Understood! Checking into that.

Ahh interesting, that was not intentional. Let me see what we can do about that.

Hi gang, We got some great feedback and excitement regarding the 5.x breakening. Thanks for that, that was great to hear. However, after some internal deliberations we’ve come to the conclusion that we did it a bit prematurely. Sorry the whiplash and to disappoint, but we are going to REVERT the repository breakup we just did and postpone it for a later date. But don’t worry, the master branch that it came from (in github.com/2600hz/kazoo) has also been restored. We’ll be back to you with more news once we’ve had some time to re-group on this work.

Well, specifically you push the transfer key on whatever phone you're using - you'll get a dialtone. Then dial *3101, then transfer again. Then the call is parked in that slot.

Re #2 it is only available via API I believe. It is untested, so that's why it's not in the GUI yet. It is called max-members and you set it on a conference object.

1) We've heard this concern before, but it's been 15 years now and we've had exactly 0 instances of abuse. But, it's possible. 2) The conference limiter has no relation to the trunks. You are limited by whichever is lower. You do need a trunk for someone to call in from the outside but let's say you have 5 inbound trunks and 5 local extensions also call in but your conference is limited to 8, well two of those people aren't going to be let in.

1) Correct. 2) It's how many people are in the bridge overall regardless of where they're calling from.