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.