RuhNet

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.