mc_

You still swap the account token for an auth token: https://docs.2600hz.com/dev/applications/crossbar/doc/api_authentication/

People still have Panasonic equipment in the field to support.

CentOS7-Rocky8 in-place upgrade, followed by a Rocky8-9 upgrade immediately after, is what we're targeting.

Nice, didn't know about that. Thanks for the pointer

Not sure the UI app is open-source but the APIs they use are: https://docs.2600hz.com/dev/applications/crossbar/doc/resources/

For clarity: we leveraged mod_erlang_event at the start of the project. We wrote, from scratch, mod_kazoo to better handle our use cases. The main one was mod_erlang_event expected only one Erlang node to connect to the FreeSWITCH node; it was a happy bug in handling connections that allowed us to have multiple ecallmgrs connect to mod_erlang_event. But there are many performance and features in mod_kazoo that KAZOO utilizes that mod_erlang_event didn't provide. mod_erlang_event is also written (and probably not maintained anymore) by Andrew Thompson (aka Vagabond). I'm not surprised the code isn't working. In short, mod_erlang_event is not compatible with KAZOO installations - any use or issues with it can be taken up with Signalwire but not sure they're keen on maintaining it either.

Check the INVITE and 200 packets' SDP payloads, verify the correct IP is present for FreeSWITCH's packet at least.

Check the SDP on the legs. FreeSWITCH should use your ext-sip-ip and ext-rtp-ip if bridging direct to the device over the WAN in the SDP.

Yes, running KAZOO in NAT'd environments requires this. I wonder how many clusters run like this?

@airsaywelcome! Thanks for the kind words. Look forward to your questions.

Agreed on having skin in the game, especially because we know they're using KAZOO as a core component of their main line of business. They're content to make a go of it alone though.

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