As part of this release, we’re trying to do a better job communicating changes and launch dates with you, before those changes go live. This email represents a "heads up" on all the new major features, bugfixes and backend improvements coming out in Kazoo 4.0. You’ll soon be able to demo these changes yourself on a new test environment (stay tuned for that announcement), and then we’ll announce a formal upgrade date once you’ve kicked the tires yourself.
We have built support to utilize Amazon S3 as a storage provider (in conjunction with the new Couch Connector features). The engine allows you to configure a different Amazon S3 account and folder for each type of item stored, on a per-user, per-account, per-reseller or system-wide basis.
Kazoo Admins and Resellers will need to decide on a strategy for signing up and maintaining Amazon S3 accounts for either all customers, or a single sign-up that has permissions across their customers, or similar variations. In addition, customers are solely responsible for managing the keys and credentials for the Amazon S3 service and inputting them into Kazoo.
We have built support to utilize Google Drive as a storage provider (in conjunction with the new Couch Connector features). The engine allows you to configure a different Google Drive account and folder for each type of item stored, on a per-user, per-account, per-reseller or system-wide basis.
Kazoo Admins and Resellers will need to decide on a strategy for signing up and maintaining Google Drive accounts for either all customers, or a single sign-up that has permissions across their customers, or similar variations. In addition, customers are solely responsible for managing the keys and credentials for the Google Drive service and inputting them into Kazoo.
The number management sub-system within Kazoo has been re-written to massively improve performance and stability for accounts which have 10,000 phone numbers in a single account, and for systems that have a collective total of over 1,000,000 numbers. The performance improvement will be perceived when doing number operations, especially bulk operations such as importing batches of numbers or deleting numbers.
Customer accounts will be migrated automatically the first time a phone number is modified (added/deleted/updated) within a single account. The automation will change the structure of the phone number documents within an account and on the global number database. This strategy ensures backward compatibility with the old structure, avoids risk at doing a mass-migration and avoids downtime. Please note that once an account has been upgraded to the new format, you can not downgrade to v3.xx of Kazoo.
Voicemails used to be stored in the same location as configuration settings. Accounts older than 12 months would often get too big, thus this became a design issue. Voicemails have now been redesigned so that the messages are stored in a monthly database that can be purged later.
All new voicemail messages goes into modb. All customers need to migrate their voicemail messages from 3.22 to modb, otherwise they can’t have access to those messages.
In order to issue HTTP requests Kazoo and some of the Kazoo dependencies used a third party library called iBrowse. This library did not maintain backward compatibility so there wasn’t an upgrade path readily available. This resulted in Kazoo being stuck with a number of significant bugs in iBrowse which occasionally impacted call processing. In 4.0 iBrowse has been completely removed and a more stable HTTP client sanctioned by the core Erlang team is now utilized.
This upgrade prevents customers with CNAM lookups or heavy database usage from experiencing a partial outage. In addition, developers who previously coded using iBrowse should now switch to using kz_web module.
Phone number storage has been enhanced to support a large quantity of numbers on a single account.
There is no preparation required to take advantage of this improvement.
Resellers can now manage their own inventory of numbers.
There is no preparation required to take advantage of this improvement.
Massively enhanced the number search reservation and provisioning capabilities to support private number inventories and an infinite amount of secondary providers.
There is no preparation required to take advantage of this improvement.
Kazoo is now an executable release, utilizing the Erlang release/package system. This means that the correct version of Erlang’s binaries comes with our software.
You no longer need to worry about what version of Erlang is installed on the machine. Kazoo will start with the correct version that is shipped with the Kazoo core. This behavior is similar to an executable binary.
Call recordings existed in v3 but required additional effort from resellers to handle storage of the recordings. Most users found this cumbersome. 4.0 introduces the ability to easily enable call recordings and track all call recordings in CDRs. Each CDR points to the call recording for easy lookup and retrieval. The recordings themselves can be placed on an external storage engine, such as Amazon S3, making it easier for people to manage the recordings.
SaaS customers will be able to contact support to manually enable this for a fee, until a GUI app is available which allows this automatically (at which point the fee will be removed)
Sometimes, on a long call, users wish to start and stop recordings mid-call but still have a single file result at the end of the call. In addition, calls which are transferred between callers are expected to remain in a single file. We have upgraded the system to support storing multiple parts of a call in a single file.
There is no preparation required to take advantage of this improvement.
Kazoo has always delivered multiple records for every call because it creates a CDR for each leg of a call. This can be challenging to program for if you are a developer, and can confuse users. It also makes it challenging to understand what happened during a call. We are introducing a concept called "Interaction IDs" to solve this. Interaction IDs allow you to get a unified view of all calls in the system. You can drill down to the previously available detail about each call leg once you’ve located the interaction ID (call) of interest.
There is no preparation required to take advantage of this improvement.
Kazoo now has an optional closed source module available that improves efficiency while de-duplicating events. This module has better stability and integration with FreeSWITCH and makes it easier for users to program against the API and WebSockets subsystem because they don’t need to de-duplicate messages, while still preserving redundancy and improving performance on busy systems.
Users should see some level of increased performance during call handling. No action is required.
When the system is very busy we have listeners that have connections to AMQP. Usually, applications have one listener only. When the chatter on the channel attached to the listener gets too busy overall performance of the system is impacted. We now allow configuration for multiple connections which results in multiple messages getting processed in a more timely manner, even if the system is busy. This helps scale large systems.
Users should see some level of increased performance during call handling. No action is required.
Previously, Kazoo set variables within FreeSWITCH one at a time. Each variable that was set also resulted in waiting for a response from FreeSWITCH. This could take 10-50ms per variable. If five variables were set, that represented a delay of as high as 250ms. We have introduced a new method that sets all variables at once. This should speed up call setup and processing times.
Users should see some level of increased performance during call handling. No action is required.
We are now configuring TLS and SRTP support out of the box. We will soon also utilize "letsencrypt.com" to auto-generate certificates. This will help with configuring and utilizing SRTP encryption and WebRTC services.
There is no preparation required to take advantage of this improvement.
As typically deployed, the web UI communicates to a Kazoo API server. The two URLs to do this are not necessarily on the same domain. This causes browsers to send an OPTIONS pre-flight request which significantly slows down the UI. Through new deployment procedures, we are eliminating these extraneous requests.
There is no preparation required to take advantage of this improvement.
A major feature enhancement was added to 4.0 which allows for generic background processes to be queued across a cluster. This feature represents a framework for adding background jobs to a queue and then popping them off, processing them and returning the results. Individual APIs can now be built that take advantage of this queueing mechanism.
There is no preparation required to take advantage of this improvement.
Bandwidth.com has stopped using the old API subsystem on my.bandwidth.com, which we used to rely on. This required re-coding the bandwidth.com module which allows for searching and purchasing of phone numbers. The new bandwidth API for purchasing and searching for numbers provides better service from the customer’s perspective and allows us to continue supporting this provider.
There is no preparation required to take advantage of this improvement.
2600Hz has added backend support for VoIP Innovations as a carrier module. This allows customers to search, buy numbers, configure E911 and manage settings for numbers on a VoIP Innovations wholesale account, through Kazoo.
There is no preparation required to take advantage of this improvement.
We have introduced a new closed-source module named "Konami Pro" which includes upgrades to the back-end architecture that make Konami more reliable. Konami creates many processes that do things that sometimes clashed with each other. Furthermore, if there isn’t a metaflow associated with a device or user, then the crossbar channel APIs doesn’t work. This update allows you to access many in call features including intercepting, transferring calls to other devices, call recording, etc.
Customers will need to update their service plans to take advantage of this feature. A new configuration to activate Konami Pro will be made available relative to users/accounts/devices in SmartPBX soon. This upgrade introduces only the back-end API calls for now.
Konami now formally supports in-call transfers along with other in-call codes. If you’re on a call, you can press a code to activate these features (call recording, call transfer, etc).
Customers will need to update their service plans to take advantage of this feature. A new configuration to activate Konami Pro will be made available relative to users/accounts/devices in SmartPBX soon. This upgrade introduces only the back-end API calls for now.
Konami now formally supports API commands to control an in-progress call. Instead of in-call codes, you can also use APIs to activate the same actions (intercept a call, call recording, call transfering, etc).
Customers will need to update their service plans to take advantage of this feature. A new configuration to activate Konami Pro will be made available relative to users/accounts/devices in SmartPBX soon. This upgrade introduces only the back-end API calls for now.
Sometimes a customer’s voicemail box fills up erroneously, usually because it is misconfigured (but sometimes because the voicemail to email application is having an issue sending emails, in which case the voicemails are retained). This requires clearing out the voicemails in the mailbox later, which is tedious. This enhancement introduces the ability to clear a voicemail box all at once.
There is no preparation required to take advantage of this improvement.
We are now including HTTPS support as the default strategy for all interactions with Kazoo. Soon, we will sunset support for raw unencrypted HTTP requests.
You should switch your application to use HTTPS if you are calling our APIs directly.
The phone numbers API was updated heavily. A lot of work was put into getting the new number manager to "speak" the same API as the old API used to. However, it’s possible 100% backward compatibility has not been obtained. Mishaps may occur.
If you have done your own integrations to our number manager, you should test APIs for phone numbers to be sure they work as expected. Most of the changes are in the DB storage mechanism and should be transparent but this will not be code we can roll back once it’s out, so please proceed with caution.
Kazoo now properly logs CDRs when calling between accounts on the same system. Previously, the CDR would only be in a single account.
There is no preparation required to take advantage of this improvement.
Kazoo now properly authorizes calls when calling between accounts. This allows billing to work properly when calling between accounts on the same cluster.
There is no preparation required to take advantage of this improvement.
Kazoo now properly handles fax calls between two T.38 devices on the same cluster.
There is no preparation required to take advantage of this improvement.
You can now transfer calls to your clients/across accounts and the correct on hold music plays for the right account when calling between accounts.
There is no preparation required to take advantage of this improvement.
Previously, every phone which made a call would be asked for the phone’s username/password. This occurred on each call. The process of doing this can take 50-150ms in some cases, which slows down call setup times. In addition, the backend systems would have to re-check the password for a phone even though we already know the phone’s IP and port and know it’s authorized. Now, we don’t challenge already registered phones if the INVITE comes from the same IP and port as a previous call. This improves performance on things like park/transfer. This also reduces all call setup time and reduces post dial delay.
There is no preparation required to take advantage of this improvement.
We now properly lookup and address WebRTC clients when calling inbound. This will help ensure WebRTC connectivity when calling to WebRTC users.
There is no preparation required to take advantage of this improvement.
The forgot password button previously reset a password on the fly and emailed the new password. Malicious users could submit false password requests that required no confirmation. The system has been updated to work more like other systems where an email with a token/link is sent first to confirm the user really requested the password reset, and then the password is reset once the link is clicked on.
There is no preparation required to take advantage of this improvement.
We have had blacklists for a while, but they have not had a way to handle Anonymous Caller IDs on inbound phone calls. Now the blacklist app will not attempt to try to normalize an anonymous caller ID, which means that blacklisting "all zeros" (anonymous caller ID) will now work correctly.
If you are using the blacklist APIs, you can now block anonymous caller IDs.
Previously, an issue existed where the API would not validate the pvt_type you submitted against the existing document. This means that if you were trying to update a voicemail box via the API, but accidentally passed in the document ID of something else (like the account or user), the system would happily accept the update - and break the corresponding document/feature you incorrectly specified. While this error is caused by the user/developer, Kazoo has been upgraded to be stricter about enforcing the pvt_type stays the same so that this error can’t be made accidentally.
If you are using our APIs from your own scripts, you should be aware of this validation in case you somehow cause an error by trying to change the pvt_type (although you should never do that anyway, so it just means you should fix your code).