RuhNet

I meant that their releasing anything open source is a "side gig" since it's not integral to their business at this point.

LOL -- I'm working with some companies on projects that are taking even longer than that. But the thing is, Kazoo v5 is completed and has been in production for several years. It's just the open source release of it that has been delayed. Now, that's not to say that they _couldn't_ have released it sooner if things were planned/managed better. But the thing is, they run a business, and releasing the open source code is only a "side gig" thing and isn't actually a huge benefit to the business side of things (it is some, but not nearly as much as people think). Clearly the open source release isn't their "priority" or it would have already been released, but that doesn't mean it isn't an important thing on their list; and that is why this amount of time, although painful to all the persons waiting on it, isn't unreasonable.

He's just speculating. Most people don't understand the complexities of a large project like Kazoo, so it's very common for many to assume that multiple delays == cancellation. When in reality that isn't the case. I don't have any inside information on it, but having worked on some large projects myself before, 2600Hz/Ooma's timeline for bringing it out, although disappointing and frustrating so far, isn't a clear indication of Kazoo v5.x staying closed source.

No need to search for other occurrences of Iterator() — unless you have custom stuff that uses it, the Trunkstore view is the only place it appears in the Kazoo v4.3 codebase. Nice replication script—I use a simple one written in Bash but yours is more informative. One thing you can do is add some delay (minutes) between replication requests which can keep from overwhelming a server. I’ve found that if I just machine-gun style replicate a bunch of DBs sometimes RAM and CPU get slammed. Also, if worse comes to worse and you have too many issues letting Couch replicate itself, what you can do is a manual clone—in other words instead of writing a script to tell Couch what DBs to replicate, you write something that pulls each doc individually and creates it on the target machine. This way takes longer of course, but can be useful if there’s corrupted data or some other issue preventing a normal replication from succeeding fully, and you also get an internal reset of revisions on the target, since although the data is the same, it is a “new” document on the target side, and doesn’t have all the previous revision tombstones hanging around. Also, although you aren’t doing this, for the benefit of other readers, you can upgrade Bigcouch to CouchDB v3, BUT you must first upgrade to v2, and then from there to v3.

Sure---and you are correct, it needs a redirect since the path has changed. All you need is something like this: frontend couch-5986-admin-port bind 127.0.0.1:15986 default_backend couch-redir-node-admin-port backend couch-redir-node-admin-port balance roundrobin reqrep ^([^\ :]*)\ /(.*) \1\ /_node/_local/\2 #http-request replace-uri ^/(.*) /_node/_local/\1 server couch1 172.31.12.34:5984 check server couch2 172.31.23.45:5984 check server couch3 172.31.34.56:5984 check If you are using a version of HAProxy v2.0 or later then comment out the `reqrep` line and uncomment the `http-request replace-uri` line.

Don't want to get too off topic with this thread, but: Couch v2 is the supported/approved version, but I use v3. You need to modify a Trunkstore view (if you use Trunkstore) and do a redirection of the admin port using HAProxy or other server like Nginx/Caddy/whatever. There is a thread about the Trunkstore view mod here in the forums. Placement and zoning depends on your cluster size. If you are in a single DC, then there isn't a reason to do multi-zone, unless you have a large number of servers. The most common scenario I encounter when setting up clients is they have 2 zones, and I recommend a minimum of 3 DB servers in each if they want full redundancy with good performance. Then for placement I usually recommend a 2+2 split; in other words put 2 copies of each document in the local zone, and 2 copies in the remote zone. NOTE that CouchDB zones are disconnected from and have no relationship to Kazoo zones---it's a totally different system. You could have a single zone Kazoo, with 5 Couch zones if you wanted, or vice versa. I generally recommend to have as few zones as you can get by with, both for Couch and for Kazoo. (I sent you an invite as well)

Worse case scenario we can cherry pick improvement commits and “front-port” them to v5 if/when it gets released publicly.

Thanks---that would be great if you could find out---it would solve the immediate issue of upgrading past unsupported CentOS 7 for v4.3 installs at least for Kamailio, since you already have the Rocky packages for Kamailio available. Even if the configs are incompatible we could work on fixing that, as long as the Kazoo module itself in Kamailio isn't doing something that's not compatible with v4.3.

@mc_ for Kamailio specifically---are there v5 breaking changes in the Kamailio Kazoo module itself? In other words, should it work with v4.3 if 4.3 Kamailio configs were used? Or have there been breaking changes to the Kazoo module of Kamailio?

@mc_ did you ever get the "official" word on this? I'm assuming since it's been several years that the version used with Kazoo 4.3 isn't a more recent version than what FS makes available publicly, so it would be nice to know which version/tag/commit of Freeswitch sources should match Kazoo 4.3.

Do you happen to remember the details of what you tried (which versions and how installed) and what the actual problem was? I notice there is a Freeswitch package for Rocky 8 at packages.2600hz.com but I don’t know if that targets v4.3 or v5.x.

Would be a good idea to start a new thread for this, since it's unrelated to the current topic.

is the number actually added to the account?

Must have been a temporary blip—it’s working now for me as well, but was not earlier today.

@fmateo05 Not sure why you would want to do that, but you can request deletion of your forum account by going to "Account Settings" and then the "Security and Privacy" section.

If you are willing to put in the effort to give that a shot, then it would be awesome! There are a few forks of Kazoo already, but most are private. One that is not, and what I would encourage you to start from, is the Sipengines fork, which is up to date with 4.3.142, but has a number of fixes applied, as well as the improvements to ACDC that Voxter made several years back. In my forked repo I have the Sipengines branch (4.3.142.itlevel3) as well as the stock 2600hz code, and some other [minor] improvements I've made on some branches. https://github.com/ruhnet/kazoo You are welcome to use that as a base. I can't necessarily commit concretely to help a lot, but as much as I have opportunity I would love to. I normally build Kazoo on Debian, as it is my server distro of choice, but building it on Alma shouldn't be any different really. Reach out to me if you have any issues setting up your build environment or need help. :) RE CouchDB v1 (Bigcouch) on Almalinux---Noooooooo lol. v2.x is the current "supported" version by 2600Hz, but I have always used CouchDB v3.x on my installs for the past 5 years or thereabouts (since v3 came out). It requires slightly different setup (the admin port 5986 has been deprecated), but is current and performant. I believe Kazoo v5 uses Couch v3 if I remember correctly (there is some code in master branch that references it).

Yes, those packages are only for Kamailio, Freeswitch, and maybe RabbitMQ.

In fairness to 2600Hz/Ooma/mc_ , I don't recall any time there was actually a promised date, only "targets", "projections", "estimations", "hopes", "plans", etc. Personally, I'd rather be told an honest hope/estimation/target and then it not be met, than to be promised something concrete and it not be met. The messaging from 2600Hz has been clear and consistent: v5.x will be released open source. The when is the only thing that has not been as expected, and the projections and time estimations have been extended/changed etc. Anyone who has worked on large software projects knows this is difficult to avoid. The Ooma acquisition has obviously further complicated and delayed things on that front. Have the delays shrunk the community size? I would say probably. But size or involvement of the open source community I would guess is not really high on the company's priority list, particularly in light of the minimal benefit the open source community has brought to the company. I suspect that this pattern of low volume of upstream contributions from the community may be common among open source software projects which have the combination of 1. being very complex and 2. being of high monetary value to users in a competitive industry. To replicate something as complete and useful for a production environment as Kazoo 4.3, using other open source projects that are available, costs literally at the very least several hundred man-hours of work. (Trust me---I've done it before: it's not nearly as simple or straightforward as slapping together Freeswitch, Kamailio, a DB and some other things.) So, whenever the release of v5 happens, it will of course be welcome. I'm not holding my breath, for obvious reasons, and will continue working with v4.3 until then. When v5 finally comes out, I'll see what can be done to merge the changes/customizations/improvements I have made to v4.3, and hopefully use it in my systems. :) 2600Hz/Ooma employees: don't read the following paragraph. LOL 🤣 And who knows---these delays may actually strengthen and improve the Kazoo community over a longer period of time: with Centos7 going EOL in a few weeks, current users of Kazoo that have no alternative solution are of necessity going to be forking and compiling their own releases. And once you've done that, the barrier to entry for contributing upstream becomes much lower than when you are a "yum-install-freeloader-gimme-gimme-person" 🤣. So it may end up being a good thing in the long run. 🤭

@Christian King In general, when compiling from source, most people use PostgreSQL for the Kamailio DB instead of KazooDB. The Kamailio DB (regardless of backend type) is used by Kamailio for things internal to it, like keeping track of the Kamailio server's dispatcher list of Freeswitch servers, presence subscriptions, etc. As mc_ noted, there is no connection or relationship between that DB and CouchDB. In the past (around 10 years ago I think?), the 2600Hz KazooDB module actually used AMQP to request data for Kamailio's "database" (i.e. to do a lookup of a presence subscription it would send an AMQP message and some app or module of Kazoo would respond with the data. Kamailio internally saw this communication as just a standard DB lookup like using a local DB.) But for whatever reason they moved away from that system and KazooDB basically became a SQLite wrapper for all practical purposes. (Not sure what else is in the module, as it isn't open source, but I don't think it does much other than use the SQLite DB file nowdays with Kazoo v4 and above.)

Bump

Ok thanks for the clarification @mc_ I will make sure to install the open source white label app instead on clusters I build.

I don't know where it was obtained from---the last one I looked at did not have any git files, so it didn't show a git remote entry. There is a community app called "Whitelabel" that offers similar functionality. But the Branding app looks a bit more polished as far as the UI, so if it's OK to use it I would prefer to install and use it. But I don't want to use it if it's not open source or free/legal to use and was obtained through unapproved means. I know there was a company a while back selling bootlegged copies of some MonsterUI apps and there are probably some of those floating around still, so I just didn't want to inadvertently use something that wasn't allowed.

No, I'm talking about the Branding MonsterUI app that has the fingerprint icon:

Recently, I've seen the Branding app installed on some open source clusters that I have worked on for various clients, but I do not see it on GitHub. What is the licensing status of the Branding app? Is it open source, or available for purchase, or ??

Yum supports using a SOCKS5 proxy, so what I've done in cases like this is to SSH to another machine (that isn't blocked) and add the -D5000 option to SSH, which will give a SOCKS5 proxy on port 5000 that yum can connect to. Then you can use an environment variable to tell yum to use the proxy on socks5://localhost:5000. You could also use some publicly available HTTP proxy.