All Activity

Hello Should "filter_by_resource_id": false, value be be changed to true? if so, please guide command In filter list caller_id_numbers is present , as you can see below >>>> "default_rate_cost": 0, "default_rate_increment": 60, "default_rate_internal_cost": 0, "default_rate_minimum": 60, "default_rate_nocharge_time": 0, "default_rate_surcharge": 0, "default_ratedeck": "ratedeck", "filter_list": [ "direction", "route_options", "routes", "caller_id_numbers" ], "sort_by_weight": true, "trie_build_timeout_ms": 60000, "trie_lru_expires_s": 86400, "trie_module": "hon_trie", "use_trie": false, "filter_by_resource_id": false, "should_publish_system_alert": { "inbound": true, "outbound": true, "both": true } }

No, .. did you?

Will be great to run it on Debian. +1

I appreciate the suggestions and the detail. I think this will be something we try out going forward. And I'm very tempted to go the Debian route.

Just unsub from notifications and be done

Tried that before and no feedback/reply from the moderators.

@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.

Excuse me about this off-topic It is possible carry out my user account? I decided to not continue with new posts and contributions here on this forum. What do you need from my end?

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).

So I want to manage my tone and encourage others to do so also (this thread has been a pretty level discussion so far). I'm frustrated with the delays, but only in so far as they are delays beyond 2600hz's own self-imposed expectations. More than I am frustrated, I'm appreciative on the immense amount of work that goes into a project like this. To open source a project like Kazoo is something few companies do. The purpose of this post is to say, if others are also willing to help out, I would be willing to work on a fork of the 4.3 branch. The first goal of this forked-project would be to just get the current release on a supported version of the OS and make new deployments easier. (Also, maybe someone already has done this fork? If so point me in that direction) TO-DO: - Build 4.3 on Alma latest and see what works and what does not - Make it easy for those who get their own PAT from SignalWire to use their FREESwitch repos (you know, because they are not public anymore) If there is a theme for a forked 4.3 project, it is "Stability on current Alma". I have some modest resources in my lab that allows me to build and test so I can provide my own feedback on how this works. But honestly, I'm probably blind to some of the challenges we will encounter (eg CouchDB 1.0 on Alma 9???). This brings me back to Ooma/2600hz - if they are close to a release, this is not worth the effort. But it seems we will just never know until it actually happens (which could be never). I manage a couple production deployments of 4.3 and they work well. But I'll soon get heat for Centos 7 and we will have to make a move. If I don't act soon, I'll likely be forced to jettison Kazoo for Asterisk. I really like the architecture of Kazoo especially for its use of FREESwitch and Kamailio. Open to feedback...

What I meant was, alma 9 will be end of support in under 3 years. If it's 6 years before a distro update let alone a version update available, running kazoo open source is a massive risk. Only way to go is commercial but then, I never would have even heard of Kazoo if not for the open source community version.

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

After browsing the rpm repository i found some rocky 8 and 9 packages; but with the core not yet released https://packages.2600hz.com/rockylinux/8/

It was already mentioned the will be using Alma Linux

Even IF v5 comes out, you now know you'll have to run EOL operating systems in the future, when the v5 branch stagnates for 6+ years. I love kazoo, I submitted bug fixes (which never were approved because work was being done on v5) created community content, videos, community support. I even tried to buy commercial Kazoo but we are "too small" for it to be viable financially (under 1000 extensions) in today's competitive market. I'd love to continue with open source until we hit the threshold where I can hand off the system management to a commercial contract. But, it is what it is. I thank the kazoo Devs for building a fantastic system and I wish v5 was out before CentOS EOL

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. 🤭

How about Second Quarter of 2024 which was promised before? Will it be the same game year over the year again?

KazooCon site still down, no MarketPlace after about 6 years, and still no Kazoo v5. What good way to destroy a company reputation/products "It’s not enough to be good at what you do. In today’s business world, you must dominate." --Grant Cardone

Yes, Ooma is committed to opening 5.x but there's bureaucracy to navigate while we are still merging infrastructure and teams after the acquisition. I have tentative targets of October for that to happen. If anything changes, I'll let folks know but I continue to be assured that this is happening.

Is kazoo 5 opensource coming? In past years many people have left kazoo and moved to other options in market. its very frustrating with no clear news..

I want to try, but i cant think of a way to implement the above, let me clarify in case we did not describe correctly the situation. So, Case1: Person A calls Person B, (Person B is free to talk) so Person B gets normally ringed and person A hears normal ringback tone. Case2: Person A calls Person B, (Person B is busy talking) so Person B now only sees in screen that he has a second call on the back(and maybe hears a tone, device settings) and PERSON A still gets the same ringback tone as Case1. In my Country when you call someone and he is "busy" BUT HAS enabled call waiting , you get a little tone every other second, or you get a voiceback saying the user you are calling right now is busy, please wait until he picks up. So how would i differentiate the callflow of Case1 with Case2. Thank you, i hope i explained it better now.

Each callflow can take a ringback param: https://docs.2600hz.com/dev/applications/crossbar/doc/callflows/ I suspect ringback.transfer might be used? Test and let us know

Dear Kazoo devs/coms, Is there any update on this? is it implemented allready somehow?

+1

@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.)