mc_

@Mark McDonaldThis seems off-topic for the post. Search what's existing related to stir/shaken or start a new post please.

Speaking personally, I think this is fantastic and I hope this will bolster my case internally for why we should be opening 5 up.

Welcome @Heriberto!

Welcome!

I guess I would ask what purpose the other tenent-based cloud system is providing and why you are using KAZOO (also a tenant-based cloud system) as a class 5 switch for them? Connectivity/trunkstore is more class 4 switching hence why extension dialing isn't supported

No, extension dialing is not supported by connectivity/trunkstore devices. KAZOO will recv the dialed number from your PBX and try to route it via the carriers (the stepswitch app in KAZOO). So 5200 won't be routed if you use it. IP auth for cust1 will require all calls from that IP to associate with cust1 on KAZOO.

Sadly the update is 5.x release is now targeting early 2025. Your guess is as good as mine whether that target will be hit. Continual assurances on open sourcing being the goal but the delays keep mounting so...

While looking for other things elsewhere, stumbled on this post: https://developer.signalwire.com/freeswitch/FreeSWITCH-Explained/Modules/mod_kazoo_10683641/ Defines key differences at the time

I don't know the specifics but I know a lot of the configs are different in 5.x. Some consolidated or deprecated. Not sure how Kam in 5.x would react to 4.3 Kam configs. Will pose to Luis and see

mod_erlang_event and mod_kazoo are totally separate in design and intention so they aren't drop-in replacements for each other. I don't know the status of mod_kazoo work or who on our (Ooma/2600Hz) side has access to merge that commit but it is not critical to merge at the moment since Kazoo 4.3 is targeted at OTP 19.3. I'll ask around about whether mod_kazoo can be opened up to the community for more PRs and permissions.

Yes the CI stuff that builds those is only targeting 5.x branches.

docs site is working from here

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.

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

depends on your use case I guess, clients can have mobile devices with SIP clients on them, or softphones on their laptops as they travel.

KAZOO only tracks the latest registration for a given credential, so the most recent one will be used for call routing.

Welcome aboard!

The situation was that marketing was done with Kazoocon and we didn't have official word that there'd be a 2024 Kazoocon, so they decommissioned the site. Word is, there will be a 2024 Kazoocon, so the site should be re-instated in the next day or two (whenever our ops team can turn it back up).

You're correct that Kamailio interacts with KAZOO via AMQP, does not contact CouchDB, and does use sqlite for local storage stuff. Kamailio is part of the "cluster" because of the AMQP connection. I can't speak to the packaging issues though. The process to open sourcing Kazoo5 work continues to wind through the appropriate channels; should resolve so many of these issues. Apologies for the frustrations in the mean time.

The KAZOO logs will probably be more helpful. Check that you're logging at debug level, place the call, then you can use the call ID to search the logs for what kazoo tried

Checking on the site, shouldn't be down. Thanks for the alert

@RuhNet definitely a private app that appears to have been exfiltrated. We know of someone (or someones) who had sandbox access that appear to have taken several private UI apps this way. The APIs are open for what the branding app does, but the UI code is not. I don't know what we can do about it but if you want to share any information privately, feel free to contact me and we can look into it.

To be clear, it doesn't exist because this is quite possibly the first time in 13 years someone has actually wanted to use this in KAZOO. So, while your request might be widely accepted, in practice it does not seem to be widely desired within the KAZOO userbase (or folks just don't mention the lack of this feature as important). If this is a typical thing Teams will be doing, however, it could end up on our roadmap, as we do have the Teams integration now. Will pass along to our team managing that, thanks!

That is not a supported way to dial, no. You could see about using the sleep and send_dtmf callflow actions via the channels API. In general, there aren't many ways to interact with an established b-leg via the callflow itself (most actions like user/device/resources will block in the action while the bridge is up, and only continue processing the callflow on SIP error).

Bienvenue!