Official Kazoo Training - June 2-4
Official FreeSWITCH Training - June 23-25
New Kazoo Internationalization Feature
Great news for our international developers!
We just rolled the Internationalization feature (I18n) on to the Kazoo platform, which means the Kazoo UI is no longer hardwired for English. Every single message, text, and error displayed on the UI can be translated into a native language. For now, only Russian and English are available, though our engineers are already hard at work expanding this in the coming weeks and months. The SIPLABS team from Russia, led by Mikhail Rodionov, were the original developers of the Internationalization feature through Kazoo v3.0.
We were able to get ahold of Mikhail early this week to talk:
2600hz: “What are you doing now?”
MR: “I’m CEO of SIPLABS LLC. Our company works with various open-source communication solutions like Kazoo, sipXecs, FreeSWITCH, etc.: we deploy, support and develop for them. We are good friends of Yealink and developed Yealink plugin for sipXecs.”
2600hz: “Have you contributed to other open-source projects before?”
MR: “Yes. Various translations, Yealink plugins for sipXecs, but there are many more projects on the go, mostly related to Kazoo which is super-hot and became our main offering over the last few months.”
2600hz: “How long did it take you to develop the internationalization feature?”
MR: “Actually – a couple of weeks. But getting into Kazoo took about a year before that. We started doing real projects with Kazoo when Kazoo 3.0 came out.”
2600hz: “As a computer engineer, how difficult was it to build this on the Kazoo platform?”
MR: “Well, Kazoo is not for the average Joe. But it’s a beautiful masterpiece! I’m really happy that we found it and invested a lot of time to get into it.”
2600hz: “Why did you develop on Kazoo compared to other platforms?”
MR: “What other platforms, haha. Seriously – there is nothing (in open source world) we know even comparable to Kazoo in terms of architecture and possibilities.”
2600Hz: “What can we do to help other developers to contribute to the project?”
MR: “Well – my main suggestion would be to create an open Kazoo Development 101-type course available to everyone that is interested.”
2600Hz: “Now that the internationalization feature has been merged into the project, are you working on any other feature that you’re planning to contribute to the Kazoo platform?”
MR: “Yes there are actually a lot of projects we are working on like regexp list management API (for black/white lists and address books), callflow module (list match), eavesdropping feature code, etc. We are to actively participate in i18n for the whole platform, including notification templates, error messages, number classifiers, user data, and more. We are also internally developing other modules, including user and device groups with inheritable group properties, boss-secretary features, call QA (bridging call to QA Pivot script after one party has hang up), and a hell of a lot of provisioning stuff. Most of this stuff is going to be contributed in near future.
We also have plans on separate Kazoo-friendly project which we call Phone Feature Server (PFS). It’s set of server-side scripts integrated to the platform that will enable full power of modern VoIP phones (XML scripting, all buttons working, phone profile management, address book management and searching, etc). Will it be open source? Maybe!”
Kazoo is a scalable, distributed, cloud-based telephony platform that allows you to build powerful applications with a rich set of APIs. 2600hz designed KAZOO to be the first system that provides total control and ownership of communications. It hosts thousands of developers such as Mikhail in an open-sourced and scalable environment.
Learn more about what you can do with Kazoo! Sign Up Today
Our Russian Open-Source Contributors at SIPLABS
ClueCon Tickets On Sale Now!
We’re excited to announce that our friends at FreeSWITCH are doing yet another awesome ClueCon event, which we’re planning to attend. This year will be hosted in Chicago, August 4-7.
Tickets just went on sale! ClueCon is one of our favorite tech events of the year, so please consider attending and supporting the FreeSWITCH project.
Check out www.cluecon.com for more details!
Kamailio World is Almost Here!
Mark your calendar! We’re excited to again be participating in Kamailio World in Berlin, Germany from April 2nd - 4th. Kamailio World is a conference dedicated to real-time communication systems, and Kamailio SIP Server and related projects. This event lets us learn and share experiences with a forward-thinking community, while hanging out with our European friends. CTO Karl Anderson will be presenting on how 2600hz used Kamailio’s module system to closely integrate with the Kazoo project, demonstrating how we had built the db_kazoo module and its mechanisms. This helped offload heavy SIP traffic volume from FreeSWITCH and provided a significant improvement to the efficiency of the cluster.
Since last years’ event, we have made great strides in our integration with Kamailio and have deployed it as part of our standard install all over the world. As we are bringing new features and expand to International Markets, Kamailio is playing an important role as our Session Border Controller (SBC). Customers can now utilize 2600hz’s platform to send and receive calls in Europe, Asia, Australia, and South America as well as its existing pool in North America. We were able to do this by integrating our service with Voxbone, opening up the path to enhance mobile carrier relationships to international customers. Additionally, our European hosted offering has been expanding rapidly and bring exciting new community members. Already community members have introduced internationalization (I18n) to the Kazoo User Interface (UI). Currently supporting Russian and English, our French engineers are already hard at work expanding this in the coming weeks and months.
Last but not least, we are proud to announce that we received the Business Initiatives prize at the 2013 Kamailio Awards for our work over the previous year.
This promises to be our most exciting Kamailio World yet! Please come join us and meet folks from our team as well as everyone else at Kamailio World. Follow us on Twitter for Live updates.
Take a look at Kamailio World’s schedule of events, Here
2600hz Expands Service to International Markets
Great news for our international customers! 2600hz will begin selling phone numbers in international markets. Customers can now utilize 2600hz’s platform to send and receive calls in Europe, Asia, Australia, and South America as well as its existing pool in North America. We were able to do this by integrating our service with Voxbone, a telecommunications company that provides voice services for carriers, cloud communications providers and enterprise contact centers in international markets. As 2600hz continues to expand its international footprint, this partnership opens up the path to enhance mobile carrier relationships to international customers.
2600hz provides service to over 20,000 users in both a cloud and dedicated installation environment. Customers include ITSPs, fiber optic network providers, channel resellers and mobile network operators. Voxbone’s APIs complement our own set of over 130 telecommunication APIs and services.
“Delivering a service from the PSTN is usually a slow and cumbersome provisioning process,” said Darren Schreiber, CEO of 2600hz. “With Voxbone, we are able to achieve real-time provisioning and a consistent high quality service on a global scale. No other vendor we considered was able to meet those needs.”
Voxbone is the only telecom service provider that can deliver uniform international DID coverage in over 50 countries with online and real-time provisioning. Its speed of provisioning enables real-time API deployment for its customers and its high quality of service allows companies, like 2600hz to efficiently connect their communication applications to telephone networks.
“Voxbone’s services, combined with our real-time API provisioning, are a perfect match for voice application developers such as 2600hz,” says Itay Rosenfeld, CEO of Voxbone. “2600hz’s selection of Voxbone’s API confirms Voxbone is the provider of choice to connect the telecom API community to the PSTN. We are confident our position as a leader will continue as we further enhance our API to meet the needs of the API community.”
2600hz CEO Darren Schreiber discusses the Mobile APIs and how people can do a SIP handoff to their own switch. So if you like telecom, APIs or just want to learn more about how Mobile works then please watch. Thank you OrangeFab for hosting us in San Francisco.
2600hz Mobile on the VUC
VoIP Users Conference
Tomorrow, our very own Darren Schreiber will be appearing on the VoIP Users Conference (that’s Friday the 28th) at noon EST (9am PST). This will be 2600Hz’s second appearance. Darren will be discussing the 2600hz Mobile rollout, among other things. We’ll be talking about getting mobile data speeds up to 60mbps (nope, that’s not a typo!) and connecting voice calls to your very own FreeSWITCH, Asterisk or other such server.
Tune in to catch a live demo (what could go wrong???) of provisioning a mobile phone onto the new 2600hz Mobile network!
More information here:
Erlang Factory Conference + Kazoo Training
Craving your Erlang fix? This is a call for those that would like to get some training on the Erlang backend of Kazoo! We have 10 attendees so far, but would obviously love to have you join us too! Learn all about how the backend works, how to extend various apps like Crossbar and Callflows, meet the Kazoo Erlang team (which has grown recently - welcome Luis!), and have a fun time doing it. If you can make Erlang Factory the week before, all the better!
More information here:
We’re excited to again be participating in Kamailio World in Berlin, Germany April 3rd and 4th. This awesome event lets us learn a ton about the super-scalable SIP border software we use, Kamailio, while hanging out with our awesome European friends. Please come join us and meet folks from our team as well as everyone else at Kamailio World!
More information here:
And Even More Trainings…!
We’re working on finalizing some dates for Basic and Advanced (new!) training courses for Kazoo for those who can’t make the Erlang Factory.
In addition, we’ve refactored our FreeSWITCH training and are excited to launch another series of great FreeSWITCH trainings to support that awesome conference.
Please check our training site, http://www.voipkb.com, for more details - we hope to have the rooms and dates secured next week.
As always, thanks for being a part of this project.
The 2600hz Team
High Performance Telecom, Section 1: Distributed BLF + Kamailio Module
TL;DR: We wrote a Kamailio module and we rewrote BLF from scratch. It’s legit.
To say our engineers have been busy would be an understatement. We’re all about building the biggest and baddest systems on the planet, and in order to do that we have to push the barrier of what is possible. We think you’ll be quite pleased with how we’ve implemented our manifold performance improvements, and if you’re like us, this is the kind of stuff that really gets your gears going. Let’s get to it!
Performance Kazoo Kamailio Module
One major bottleneck we were aware of in v2 was our sending of registrations to FreeSWITCH in addition to phone calls. The reality is that all registrations hit Kamailio first and then go to FreeSWITCH, duplicating the work that FreeSWITCH has to do. That’s why we hired Anca Vamanu - one of the authors of some Kamailio modules and an expert C coder who has been an absolutely fantastic add to our project.
Anca helped simplify the problem - why not have registrations go to Kamailio and then to AMQP for us to handle directly? After some intense design work with our CTO, Karl Anderson, the answer was clear - treat Kazoo as a database (but really, send database requests to AMQP to be handled any way we see fit). This strategy fit in perfectly with the rest of our architecture, which utilizes AMQP as a messaging engine for real-time or configuration data. And the strategy worked! The result of connecting Kamailio directly to AMQP (and thus, our WhApps) is a massive performance improvement.
This is the culmination of six months of day in, day out work. What we’ve figured out over the last few years is that certain components in the network serve multiple roles, but that, at scale, isolating functionality is actually the best way to move forward. Our revelation was this: FreeSWITCH is one of, if not the, best media server on the market, but Kamailio is an amazing SIP Signaling program. We have, thus, stripped FreeSWITCH down to just Core Media handling and moved all non-media related signaling to our SBC, Kamailio.
But wait, why?
To understand why we did all of this work, you have to understand the crux of the issues with registrations. Registrations do two things: 1) they tell us what IP address and port the phone is operating on, and 2) they open a pinhole in the firewall; creating a small hole in the network to let traffic outside of the corporate network in. Obviously it’s of paramount importance to minimize the ports that are open on the firewall to reduce the overall attack surface (more ports open is more places the bad guys can get in). Firewalls hate open ports, particularly ports and they are designed to close inactive ones. To solve this, we (and every other vendor out there) send bogus traffic to and from the phone all day long – giving the illusion that activity is occurring between the two endpoints and allowing the pinhole to remain open.
The problem for us is that we use multiple origination servers, so when a call is being processed by us, it may not necessarily be via the server it came from last time. That’s part of distributed systems engineering, and anchoring a particular customer to a particular box is not distribution. Let me be clear this is a hard problem to solve, but we gave it our best shot!
FreeSWITCH deals with registrations in a manner we found hard to distribute. Essentially FreeSWITCH writes every Registration to a local SQLite Database (Read: SLOW!!!). You can optionally upgrade that mechanism to use Postgres or MySQL, but now you are managing a database which we find difficult to utilize in a real-time, distributed cluster. Because we haven’t found a way to distribute the registrations within FreeSWITCH, we are writing to SQLite and then buffering to Memory (Read: SLOW!!! x2). We thought there had to be a better way.
Turn out, the creators of FreeSWITCH envisioned scenarios where registrations weren’t inside FreeSWITCH. Woohoo! So we decided to circumvent the registration process completely, but still have FreeSWITCH handle calls. The results were literally nothing short of amazing.
Our new solution completely removes FreeSWITCH from the equation and routes all registrations to our Kamailio Registrar Server. This doesn’t require us to echo any messages across servers, it’s simpler, with fewer transactions, lower bandwith, less latency AND the media server can be separated from the SBC (which we couldn’t do prior to this change). Our experience is that the bottleneck in most large production networks has been registrations, and by offloading the most painful part of our stack to something purpose-built to handle those difficulties we get numerous benefits. Beyond what I’ve mentioned already, we get two other massive consequential benefits:
- FreeSWITCH is less busy so it can process more calls
- Kamailio is WAY better at handling SIP Packets for signaling than FreeSWITCH so it uses less threads overall
When FreeSWITCH isn’t doing registrations, it can support more calls (more CPU Idle for the win!). Kamailio is really really fast; we’re seeing improvements greater than 25x over our previous infrastructure implementation. This will allow us to cut our infrastructure requirements for large carrier networks significantly. We’ve also redone other portions of our network leveraging Kamailio.
High-Performance BLF Rewrite
Out of the box, FreeSWITCH excels at single server installations with all phones attached to a single box. We run a lot more than 1 FreeSWITCH server, so we have to deal with shared state across all servers. This is an incredibly challenging issue and BLF represents one of the biggest pain points – any phone may be subscribed to any box and other phones may cause the state of that subscription to change. We’d like to eliminate these kinds of difficult transactions wherever we can. When we say expensive, you can basically read that as REALLY SLOW! Basically, our Erlang Call Manager (ecallmgr) has to query each FreeSWITCH server to see who has what phone registered and which BLF subscriptions are active. Since we run 2x ecallmanager, it actually queries each FreeSWITCH server twice. Across sometimes 20 servers. So in other words, one light changing status could be 20 requests across all servers, 18 of them being discarded.
That’s a ton of packets! Literally, in a 10 freeswitch server install with 2x ecallmanagers running, we’re sending 20 packets to identify where phones are reporting BLF. This is akin to an internal denial of service attack; there’s just a very large amount of packets transversing our internal networks, and we’d like to reduce our load if possible.
Our solution was to keep a small table in memory that shows where each phone is, thereby greatly reducing the transactional costs of identifying the location of a given handset. It turns out the memory utilization is quite low. By querying one shared table as opposed to numerous individual tables, we reach consensus in one query instead of 400. One can see the 400x performance boost right there, although in real world trials it tends to be closer to 25x, as previously mentioned. That table can also be sharded across multiple servers via a key, as needed, to allow infinite growth.
To review… Performance Part 1, we rewrote BLF and wrote a Kamailio Module from scratch. Both of these new implementations bring tremendous utility to our network in the form of massive speed improvements and capacity innovation. We think you’ll love this tech, and we hope you see our passion every day when you use our work.
Does High Performance Telecom make you salivate? Would operating a network with 1/10 of your current infrastructure be beneficial to your company? We think so. Email us at email@example.com to talk about how we can help your business, today!
A Very v3 February
To start the new year off right, we’ve got one more present leftover from the holidays. As you may have heard, we’ve been crazy busy building the third version of our software. Kazoo started out as an attempt to build a better communications system and, over time, it has become one of the best available.
Today, we are pleased to announce a streamlined installation experience with the launch of theKazoo v3 ISO and the Kazoo v3 installation tool!
We hope this allows some of you still running v2 to see all of the awesome benefits of v3. We’re happy to announce further improvements in our latest version. Most notably v3 includes:
- One command installation (and single server support!)
- The Most stable and Secure Kazoo so far
- Simply Massive Performance Improvements
- Much, Much more!…
To Use the new ISO
While a wiki page for the ISO is still pending, installation should be self-explanatory. Just mount the ISO and boot, following any on-screen instructions. You must still apply IPTables yourself to secure the system, so please tread carefully as we work out some of the kinks on this ISO. For now, it’s awesome for development, but not quite recommended for production.
To Use the All-in-One Installers Script
Please head on over to https://2600hz.atlassian.net/wiki/display/docs/Kazoo+Single+Server+Install which has detailed instructions on how to use the shell script to perform a single-server installation.
We hope you enjoy using these two new additions to the 2600hz Kazoo toolset and we hope you’ll consider providing feedback and contributions to the project to keep things rolling!
The 2600hz Team
1 2 3 4 5