mc_

@Bitrate you missed it above - potential customers are using KAZOO, are not getting support contracts or custom development from us, are not submitting code or doc improvements. I can't get my team paid their salary based on potential customers who use KAZOO. These potential customers have millions in VC funding so its not a bootstrapped, garage-based startup that we're dealing with. Again, I totally hear you and wish we didn't have this tension between the commercial 2600Hz arm and the open source KAZOO arm. I will appeal to authority a bit here - I've been involved from the get-go, 2010. In that time, 2600Hz has paid me a salary to develop KAZOO, 90% of which is open source. I have maintained google groups, this forum, the docs site, IRC channel, community Slack channels, KAZOOCon, FreeSWITCH and KAZOO trainings, a bi-weekly hour-long community call, and more that I'm probably forgetting at the moment. So don't question mine or 2600Hz's commitment to the community. We've been out here for 13 years, making a go of it in OSS. We have community members here, haven't paid us a dollar, riding with us since the Whistle days. If folks fall off because we're not "open source" enough for them, go find another company or project that does it better! Bon chance to them. We are at an interesting juncture where large companies are using KAZOO without contributing, competing with our paying customers for sales. We're navigating it as best we can, both us who believe in OSS and the business side that wants to keep us employed and paid.

@BitrateI hear the frustration and I share it. However, I also think you overstate the community's contributions to KAZOO. Can you honestly quantify the impact of the community on KAZOO? This is a serious question because when I've looked at commits from non-2600Hz employees to KAZOO (from whistle 1.0 to KAZOO 4.3), Monster UI, and our doc repos, the disparity is glaring. Don't misunderstand me, I appreciate the community that does exist and contributes feedback and bug reports and I hope we get back to that sharing soon; however when businesses take KAZOO and make money off it and don't contribute (proliferate examples from mega corps on down) then its a harder task to justify the business side of keeping development open. We have costs and no VC funding so rely entirely on our paying customers to keep things moving. It's a whole debate across OSS, open core, alternative licensing, etc and I haven't seen any consensus on how to balance developing open source software and putting food on the table. Curious for all suggestions towards making OSS a sustainable way to do business?

I appreciate the discussion, but I think you all overestimate the "usefulness" of bug reports from the community and underestimate the effort we have to take to properly investigate the report. KAZOO is not closing; I will quit the company if that decision is made. I have been promised from C-level execs that what was open in v4 will be open again in v5. If that promise is reneged, my resignation will be close behind. So, I hear you all, I continue to advocate for opening sooner rather than later, there is lots going on behind the scenes, etc etc.

SELinux looks involved, you might try disabling it to let rabbitmq start.

You might instead look into defining a storage plan that can store the recordings to your S3/GoogleDrive/HTTP server of choice. A basic guide:https://docs.2600hz.com/dev/doc/blog/storage/ HTTP guide: https://docs.2600hz.com/dev/applications/crossbar/doc/storage.http/

You might try using journalctl to see what logging the rabbitmq process did? The screenshot doesn't have much useful info for why rabbit failed.

Welcome @synogeek! Glad to have you here. In many ways, KAZOO feels like a labor of love, built with good people. Appreciate the kind words! As always, constructive feedback and PRs are welcomed on improving the docs, source code (if Erlang is of interest), or feature set.

Please follow the install guide: https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/#gain-access-to-the-freeswitch-repositories The guide is backed by a git repo so any issues you find can be fixed with a pull request so all can benefit.

Welcome @Shailen! As discussed in IRC (more for future readers than you directly), KAZOO includes a make/erlang_version file to reference when building particular branches. For the 4.3 branch (current expected branch to use), OTP 19.,3 is recommended and expected to work. Versions outside of that are caveat emptor.

To Brian's point, so much has changed between 3.18 (Aug 2015 last update) and 4.3 that I don't think it's worth anyone else's time to figure it out for you, tbh. Depending on your size, I would consider standing up an independent 4.3 cluster and slowly move customers over vs upgrading from 3.18 at this point. And I would fetch the data from 3.18 via the API and send it to your 4.3 API versus copying databases over. In 4.x you can set privacy expectations on the endpoint (device or user) instead of having to modify every callflow. You might find a concept called "preflow" that would run before every callflow where you could insert the privacy action if you want (and if preflow exists in that version).

From what I remember, you have to have an SMSC that communicates over AMQP to hook up for this, which I don't think most folks have access to. I believe we built one for a customer at one point but nothing active on it in years that i know of...

Bienvenue! What's your experience with KAZOO so far?

RECOVERY_ON_TIMER_EXPIRE generally points to a firewall issue on the client side. See https://freeswitch.org/confluence/display/FREESWITCH/Hangup+Cause+Code+Table Glad you got it sorted on your end!

Outbound calls from the phones take a different path through KAZOO. But, knowing they can make calls means their credentials are likely correct. For inbound calls, you need to check the "Call History" in SmartPBX for those calls and see if there are "b-legs" generated to the devices. Check the hangup cause to give hints on why the call wasn't delivered. If this is your KAZOO cluster, you can check logs from FreeSWITCH and Kamailio for the SIP side.

You may want to investigate the phone's REGISTER sequence here. We've seen some softphones that send a REGISTER for 300s then immediately follows up with a REGISTER with no Expires header which KAZOO treats as a deregister.

Just to be an agent of chaos, work commitments have changed such that Wednesday 10 isn't a viable time now (and actually Tuesday at 9:30 has opened back up again). So Tuesday 9:30??? :)

Leaning Wednesday 10:00 pacific myself, least often to have a conflicting meeting these days. We'll see if more folks trickle in with requests; will update the calendar here on the forum once we solidify something.

The module will look for a child branch in "children" that matches the value found at "variable"'s path in the "scope" data structure. So if "scope" is "custom_channel_vars" and "variable" is "authorizing_type", the module will look for children based on "authorizing_type" (like "device", "resource", etc) in the call's "custom_channel_vars" JSON object

Some ideas here: https://docs.2600hz.com/dev/applications/callflow/doc/cf_branch_variable/

Firewalls with SIP ALG typically target UDP (and maybe TCP) packets destined for port 5060 on the remote side. When ALG can't be turned off at the client site, moving traffic to port 7000 (a typical alternative SIP port) makes the packets pass through the firewall unmolested. Adding TLS obviously encrypts the packets to keep them from being mangled as well - not required to move to 7000 to do this. Not sure if there's a standard or convention, but I think TLS-enabled connectivity targets ports 5061 and 7001 on KAZOO: https://github.com/2600hz/kazoo-configs-kamailio/blob/69840f0c5a11237b1b216072e411d3d98df006eb/kamailio/listener-defs.cfg#L9

What is KAZOO doing at this time? There are routines that run monthly for updating account balances and things like that; could also be that your server is underpowered

Check /etc/kazoo/bigcouch/local.ini the database_dir config: https://github.com/2600hz/kazoo-configs-bigcouch/blob/master/bigcouch/local.ini#L16

The API is the callflows API. These are actions within the "flow" of a callflow.: https://docs.2600hz.com/dev/applications/crossbar/doc/callflows/ About callflow structure: https://docs.2600hz.com/dev/applications/callflow/doc/

Your best bet for a system reset is, on each couch server, delete everything in /srv/db then restart kazoo-bigcouch. Then restart kazoo-applications to re-initialize system databases.

The virtual KAZOOCon this year should have some announcements in that regard.