All Activity

We officially approved releasing an OS version of 5.4 as a Senior Leadership Team about 3 weeks ago. Product management is working with engineering on this as we had to split the OS and closed-source repos. As you probably know, 2600hz pivoted years ago to having closed sourced / commercially licensed components as the company couldn't survive without generating revenue and OS wasn't doing that especially compared to the fully commercially licensed competitors of 2600hz (Netsapiens, Alianza, Broadsoft, Metaswitch and RingCentral/Intermedia/etc coming from the UCaaS space with a pure reseller model). All the closed source modules will remain such with an increasing number of those ported from the Ooma side. To be transparent, Ooma's priority has been porting over our intellectual property we built (our desktop, mobile, video conferencing, chat and custom scaling fixes) for the hundreds of commercially licensed customers of 2600hz that have wanted to tap into the tens of millions of dollars we've invested over the years as the largest operator of the platform. That being said, I'd venture to guess it'll probably be in the next 4-8 weeks as engineering has been slowly chipping away at it behind the scenes over the last 2 years and they are in a state where they are generally ready. It's not going to come with much documentation. There are significant improvements in the 5.X family compared to 4.3 although some of those for scaling are tied to closed source modules that have long existed. It was a bit complicated when we acquired 2600hz as they had pivoted their strategy to still having open source but tying it to the new marketplace and there was still a lot of work to be done. They were pretty focused on their commercially licensed customers. That being said, we recognize the value of open source as that is where Ooma started years ago with the platform and then we wanted 2600hz to continue to survive and make money so we entered into a relationship where we could compensate them in a meaningful way to help fund all the developers (the majority of the company was and is R&D resources). Hope that helps! This wasn't purposeful. That site was tied to a credit card we didn't know about in the acquisition, it expired and the hosting provider deleted everything. So we had no way to recover it. We would've gladly left it up (like prior KazooCon videos on youtube). Do see my prior post on open source though. We also can't use Kazoo anymore as the trademark lapsed years ago (another neat thing we wound up discovering) and another company snagged it and wouldn't sell it to Ooma.

It's the end of August. What is the release of 5.4 OS looking look at this point?

Thanks. Currently I have it installed and set up with a lot of configurable brands also. Currently, running some cisco and yealink phone devices. They registered instantly, I could enable some featured keys.

Hello All, My name is Eric and I started my new role this week on our Technical Customer Support team. I look forward to working with you all! Thanks, Eric

Hello Everybody, My name is Naman Kamdar, and I have joined as a technical support specialist for the 2600 Hz project! It feels great to connect with you all!

How can I restrict a user from receiving calls from a specific user or a specific number in Kazoo? I would also like to limit the numbers a user can dial.

If you haven't joined the Discord already, please pop by and say hi. There's a whole channel dedicated to STIR/SHAKEN with a working implementation available for 4.3.

Welcome! https://docs.2600hz.com/ consider checking the docs site out (though it has both legacy 4.3 and current 5.x docs so make sure you're looking at the right ones for your install).

Hi. I am a newbie using this platform. Exploring some documentation to learn about it. Which documentation may you recommend?

What are you looking for help on?

Thanks for let it know. wntpftp.!

@fmateo05 Hi there! Just a quick update — we’ve officially moved all of our documentation to our new site: docs.2600hz.com. You’ll find all the legacy Monster UI documentation there, along with a bunch of other helpful resources. As for open source, we’re still planning on it! That being said, we don’t have a formal timeline just yet. When it does happen, it’ll be based on version 5.4.

Also in the .org website there is no update for a long time.

That's why I keep saying Kazoo 5 is dead. Their very last KazooCon, they made all the videos unlisted, and no update on the project in over 5 years. The KazooCon site has been removed. It's dead. Even if you take a look at their main web site, there is zero mention of anything open source. It's all SaaS/Cloud now.

I cannot see the 'Monster App's' Section; what is going on? (wntpftp!)

Hi, my name is Tim and I am the IT Manager for our company. We recently started using Kazoo (Monster UI) for our Simple Phone system. I have it working but need some help on advanced features.

Wow!! This is excellent! Yeah, we definitely want to be part of testing this and getting it stable on a current OS. Good move you guys!

@mc_ It's really not off topic as stir/shaken is required to keep 4.3 running past June. One of the primary project goals of the fork is implementing stir/shaken. I can't find any posts other than this about it:

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

@mc_, can you point me in the right direction as to where you guys added stir/shaken in v5?

https://github.com/fmateo05/provisioner-wfusionpbx-webhook -- This one is the last one; it uses a different scope

Is this repository (https://github.com/fmateo05/provisioner) up to date with your recent changes?

Yes, Now I did it.

l problema que enfrento es el siguiente: mi empresa desea contratar un troncal SIP para ofrecer servicios de PBX en la nube. Mi proveedor de troncales me ha indicado que debo compatibilizar mi sistema (Kazoo) con la tecnología que utilizan, que es un IMS de Huawei. El inconveniente surge al momento de manejar las causas de las llamadas colgadas. El IMS trabaja con ISUP o Q.850, en lugar de utilizar las causas SIP que provocaron la desconexión. Por ejemplo, cuando se realiza una llamada a un usuario que no responde, el sistema devuelve un 486 USER_BUSY en la causa SIP, pero siempre responde con Reason: Q.850;cause=16;text="NORMAL_CLEARING". Esto se repite en situaciones como llamadas rechazadas, usario no responde o usuarios ocupados. En todos estos casos, el proveedor me ha indicado que, debido a esta inconsistencia, no podian ofrecerme el troncal SIP. Esto se debe a que por ejmplo podia ofrcer un mal servicio a la red telefonica de la pstn `pr ejemplo si un número de la PSTN llama a un troncal asociado a un usuario en Kazoo que está ocupado, el IMS devuelve "NORMAL_CLEARING" (causa 16) en lugar de "USER_BUSY" (causa 17). Como resultado, el número que llama recibe una respuesta que indica que la llamada se ha colgado normalmente, en lugar de un mensaje que informe que el usuario está ocupado. He intentado resolver esto de manera parcial y me va adar el tronco sip pero fue que lo engañe utilizando una modificación en FreeSWITCH, pero esto ha afectado el funcionamiento general de Kazoo. Modifiqué el archivo ecallmgr_fs_bridge.erl en el código fuente y cambié la función spec pre_exec(kz_term:proplist(), atom(), kz_term:ne_binary(), channel(), kz_json:object()) -> kz_term:proplist(). para establecer continue_on_fail en false pues lo tenia en true y añadí {"application", "set sip_ignore_remote_cause=true"}. Esto hace que, si el puente falla, no continúe el plan de marcado y se ignore la causa remota de la desconexión. Sin embargo, esto ha generado un problema: si el usuario le activo el buzon de voz el funcionamiento real deberia ser no hizo el puente continua plan de marcado y llega a su buzon de voz sin embargo como continue_on_fail en false nunca se llega a la parte del puente, y no llega al buzon de voz. Aclara tambien que si el usuario no tiene ningun dispositivo registrado siemre siempre devuelve SIP/2.0 480 Temporarily Unavailable con la causa Q.850;cause=16;text="NORMAL_CLEARING". Cabe mencionar que otros errores, como "no route destination" o "incompatible destination", unallocated: number devuelven correctamente el Reason: Q.850 corres`pondiente ¿Podrías orientarme sobre cómo podría corregir esto para lograr una mejor compatibilidad y que Kazoo funcione adecuadamente? He observado en los logs de Kazoo y FreeSWITCH que el canal se cierra con exec: uuid_kill(UUID) y que, por defecto, esta API de FreeSWITCH siempre finaliza con causa 16 (normal clearing). Sin embargo, sé que si ejecutas exec: uuid_kill UUID, puedes especificar una causa, como 17, para cerrar el canal. No estoy seguro de cómo implementar esta opción y en qué parte podría mapear la causa para finalizar la llamada con la causa correcta. Agradezco de antemano cualquier orientación que puedas brindarme