All Activity

Soft transition from customers that are on office cloud based systems (with similar FromIP) and cloud based system to kazoo onprem. Some have more advanced SDK driven call control applications to then dial 4 digit dial across and in terms of migrations. CustA is on existing PBX but we are slowing added customer to kazoo so interim we do 4 digit dialing. Other PBX cluster systems without DID number to just dial xxx over a trunk like Mitel - Freepbx days but in this case its def different as anything and everything is DID driven. We did also do a customer and created fake DIDs 1xxx-xxx-xxxxt to insert/remove and auto assign but there is a headache in managing this way for each customer on xxxx did. It did work for 1 Customer. and not dynamic to any callflow (unless maybe we modify the insert) OR what if we modified FS directory and did a domain matching based and takes out the dynamicness of Kazoo. I did do a route you suggested a few years back with adding Device as IP Auth and it woks that way for cust1.kaz.com but when I add another customer from the same cloud Carrier. I Try to call from the same cloud system custb.domain.com to kazoo cluster cust2.kaz.com domain routing but it chooses that account with the device IP auth. We thought of doing fake IPs per customer to auth based but hard to find a viable solution. i thought trunkstore would do the trick or potentially modifying the function doc in the lookup_did /lookup_user_flags but that is way far beyond my scope. Or maybe we look at a kamailio front proxy to route different things but If there is something like this what would be it called to even consider a feature request for the PBX trunkstore config. Like me i thought sip domain based auth routing it would just work ext to ext dialing.

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

Oh so if we have multiple customer on the Same FROM IP (tenant based cloud system) this wont work. will this be something on 5.x if it comes out to community. workaround i swapped the from header as the to domain also from domain. and put a X-Header in to process via a middle proxy agent box but that seems hacky but it works but hoping it could treat it like a pbx trunk 4digit dialing across.

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.

You can use couchdb v3 fine on 4.3. it's more about couchdb zoning, which is well documented. This is the discord invite again for another 7 days. It's not a support channel though, it's for those wanting to contribute to efforts in maintaining 4.3. https://discord.gg/r77hSf89

@mc_ Question on this (i have a multi-tenant PBX) that wants to route via cust2.kazoo.sip.com DNS name to multiple Tenants on kazoo cluster. If i add IP auth on 1 account it worked but now i have another tenant from same PBX and i need send the same 5200@cust2.kazoo.sip.com (the DNS FROM is different) but i think cause IP auth it all goes to 5200@cust1.kazoo.sip.com even though i called 5200@cust2.kazoo.sip.com is there a way to make it pure like PBX trunk send to 5200.cust2.kazoo.sip.com can it use DNS to route that . (4 digit dialing between PBX to kazoo) back in the past i did a add device / authentication IP auth (but this trunk has SIP based auth too so should it work that way> ?) would i be able to PATCH the connectivity API to inbound route like this ? { "servers": [ { "server_name": "pbxa.sip.telexxxx.com", "auth": { "auth_method": "username", "auth_user": "user93k92", "auth_realm": "pbxa.sip.telexxxx.com" }, "options": { "inbound_format": "domain", "enabled": true, "media_handling": "bypass", "force_outbound": false } } ] }

Don't want to get too off topic with this thread, but: Couch v2 is the supported/approved version, but I use v3. You need to modify a Trunkstore view (if you use Trunkstore) and do a redirection of the admin port using HAProxy or other server like Nginx/Caddy/whatever. There is a thread about the Trunkstore view mod here in the forums. Placement and zoning depends on your cluster size. If you are in a single DC, then there isn't a reason to do multi-zone, unless you have a large number of servers. The most common scenario I encounter when setting up clients is they have 2 zones, and I recommend a minimum of 3 DB servers in each if they want full redundancy with good performance. Then for placement I usually recommend a 2+2 split; in other words put 2 copies of each document in the local zone, and 2 copies in the remote zone. NOTE that CouchDB zones are disconnected from and have no relationship to Kazoo zones---it's a totally different system. You could have a single zone Kazoo, with 5 Couch zones if you wanted, or vice versa. I generally recommend to have as few zones as you can get by with, both for Couch and for Kazoo. (I sent you an invite as well)

Does anyone have an updated install plan for creating the multizone cluster on couchdb 2/3? Im having trouble understanding the placement and zoning options for couch, but would like to be running on a newer version when building a 4.3 cluster. Also can you post the discord invite again, it expired. id love to be able to help in anyway that i can.

There's also the 4.3 build that has been done for 4.3 via the kazoo-classic repo. https://github.com/kazoo-classic/kazoo/releases/tag/v4.3-1-alpha I'd like to thank the others in the Discord for their monumental effort to getting 4.3 running on newer OS's and updated dependencies.

From discord : In an effort to try and make things easier for people to test I've uploaded pre-built releases: kazoo-4.4: https://github.com/kageds/kazoo_applications/releases/download/0.1/kazoo-4.4.tar.gz and Freeswitch: https://github.com/kageds/freeswitch/releases/download/0.1/freeswitch.TGZ

That is disappointing to hear, but not unexpected. As always James thank you for advocating for all of us!!!

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

@mc_ Have we heard any internal updates on the 5.x open source release yet?

Hello, I have customer with 3 users overseas (I believe using Yealink). I need to provision their phones to Kazoo, but before I factory reset thier phones I'd liketo make sure everything is working fine. So instead of reseting thier phones is there a way I could set up the Provisioner to use "Account 2" only on these 3 phones to test that the extensions and outbound calling works before wiping the phone?

Worse case scenario we can cherry pick improvement commits and “front-port” them to v5 if/when it gets released publicly.

For anyone in the same situation, wanting to continue to run 4.3 but on a supported OS, it's been hard forked to https://github.com/kazoo-classic as I'm going to assume 2600hz/ooma won't want to maintain or accept PRs for 4.3. Repos will be updated as we test fresh deployments of 4.3 with installation instructions. That said, I'd rather put efforts into contributing to v5, but its closed source so I'm doing what I can :)

Thank you, i'll give it a try

Give Ringotel a try. We mainly use them for audio calls through Kazoo and our own SMS platform, but video did work there if I recall correct.

Thats awesome work!!

Thanks, it worked perfectly! I created two workflows, ie *81 to Enable and *82 to Disable.

You can use Callflows and force time of day on/off/reset:

Hello, Does anyone have expierence using hosted Kazoo with a 3rd party mobile app which has video capabilites? If so could you please recommend which App. Thank you

Hello, I have a new customer who would like to the ability to turn on /off "After Hours" inbound routing rules manually (not based on time). Their old system allowed them to do this but I'm having trouble setting this up. The current inbound rule sends the calls to a "group". they want to sent the calls to a fowarding number after hours. Can a feature code be setup to change inbound rules? Any advice would be greatly appreciated

Update on 4.3 on a newer os; Not all stress tested yet, but everything is working across a mix of Debian 11+/Alma 8+, external calls working fine, just faxing and notifications/emailing to go next