Kazoo Platform

When Darren isn’t busy working on stuff in the guts of the world’s biggest Telecom Infrastructures, he’s helping to write books about FreeSWITCH with the epic FreeSWITCH team. Their latest work is available now! You can buy the book here: ... [More] http://www.packtpub.com/freeswitch-1-2/book Learn more about FreeSWITCH by checking out their site: http://freeswitch.org Thanks for letting us be a part of such an awesome open-source project!! [Less]

“The much requested deck by James Aimonetti from Kamailio World earlier this year (Epic Powerpoint)” - Every now and again we let our engineers out of the office to wreak havoc on the conference circuit. James gave an awesome presentation at Kamailio ... [More] World earlier this year and we’ve had a bunch of requests for the deck. SO, without further adieu, I’d like to present “Kazoo” by James Aimonetti, presented earlier this year at Kamailio World (THANKS FOR THE INVITE DANIEL!!!) 2600hz Kazoo Kamailio Integration Deck from Kamailio World by James Aimonetti Do you like what you’re reading here? Is this the kind of problem you’re trying to tackle? Send us an email at [email protected] to talk about how we can help you scale, or if you’d like to solve these problems, send us an email at [email protected]. We’re looking for engineers, hackers, and people that are really passionate about communications. What are you waiting for, send us an email!! [Less]

Provisioning Sucks (And here’s what 2600hz is doing about it) This is the recap of our Provisioning Q&A session featuring Andrew Nagy of Provisioner.net and Francis Genet, lead engineer on the 2600hz Provisioning project. If you dig this kind of ... [More] stuff you should check out our next Q&A on Database Management here. If you have ever dealt with phones, chances are you hate provisioning. If you do it manually, it is exceedingly tedious. If you do it automatically, it can be disastrous. Many organizations opt for a homogenous equipment mix, supporting only one Manufacturer with a proprietary provisioning solution because it works and that’s good enough. Here at 2600hz, almost all of our clients run heterogeneous infrastructures, which means we have to handle all different manufacturers so we couldn’t use the proprietary solution. Second, we work with a lot of handsets and we realized pretty early on that manual provisioning wouldn’t work for us. So we did what any self-respecting group of telecom engineers would do: we built our own provisioner! And, since we’re awesome open-source citizens, we’ve made the code publicly available HERE too! Let’s take a look at the work we’ve done and why we’re doing it: On the shoulders of Giants It’s worth mentioning that we are hardly the only organization to wrestle with the realities of provisioning. Our work is based on Andrew Nagy’s Provisioner.net and, to quote Isaac Newton or Linus Torvalds, depending on who you ask, “If we have seen further, it is because we stand on the shoulders of Giants”. Before we start diving into what we consider the state-of-the-art, we’d like to acknowledge the great work our predecessors have done in bringing us to the point where what we’d like to achieve is possible. Alright, let’s dive in! Why is this hard? (Quick note: Cisco Handsets take up to 2.1 hours per phone to provision. That’s why having auto-provisioning is so important. Source) It’s actually not that hard to provision a single phone, or even 100 phones. Hell, it’s not that hard to provision 1000 phones if they’re at the same site and the same manufacturer. See, routers have this awesome option called DHCP Option66 which lets you point phones en masse towards a provisioning server. All of the devices that connect to the router will receive a URL in a packet header that points the phone towards the config files. This is how the process works, but it’s worth diving into how this works over the WAN in a little more detail. Let’s lay out the process for setting up a handset over a Wide Area Network: Phone arrives brand new from factory Phone has Provisioning URL added to the on-Device GUI <—- This is DHCP66 Provisioning server creates a provisioning profile for the handset containing all of the configuration files (MAC Address used for identification) The Phone is attached to the corporate network and attempts to connect to the provisioning URL in the GUI The provisioning server recognizes the MAC ID of the handset and sends the corresponding configuration files after authenticating the phone The phone receives the firmware and if this is a secure environment, performs a checksum on the configuration files to make sure they match If everything is Kosher, the phone will begin the update process. Once complete it will enter service. Every few minutes (days) or when the phone powers on, it will repeat this process starting at step 4 This process has to work every time for every handset. Now, one would think that after the 150 years of telecom that we’ve had, there might be some standardization between vendors but that’s certainly not the case with respect to provisioning. Every manufacturer has a different way crafting their provisioning files, even down to the number required to boot a phone or even the names of the files. It’s enough to drive a developer batty, but this is what we have to work with in Telecom. Seriously go look at the Polycom firmware grid; it’s like a forest of incompatible firmwares. The Polycom Nightmare Grid If you want to present your users with simple-to-consume services, you must first conceal complexity. That’s a recurring theme in all the work we do at 2600hz, but it’s perhaps no more true than what we’re doing with respect to provisioning. What are we doing about it? At 2600hz, we believe in presenting simple interfaces for complex services. When we think of provisioning, we want our clients to experience a service that “just works”. We don’t allow folks to see firmware file names because we know what works with our servers. Power users can get this functionality back with trivial difficulty, but for the majority of use cases, the default settings are perfect. Here’s what our provisioning interface looks like in our GUI: You’ll notice that we request a user to select a make and model of their phone, a name and a MAC address. The only piece of really specialized information is the MAC address; everything else is immediately obvious to the user. But provisioning the handset doesn’t govern how the handset might interact with the network. That’s why we’ve included some extra tools to take the experience just a bit further. Like take segregating Voice and Data traffic without physically separate ports. That’s hard to do without VLAN tags but who wants to manually go into each phone to program a VLAN? That’s complicated, and remember, 2600hz is all about hiding complexity: Here you’ll see a place to enter a VLAN tag. It really is that simple to push VLANs to all of your clients equipment. How do we hide all this complexity? When you check new boxes in the management interface for provisioning your handset, we make on the fly changes to the provisioning file for that phone. If you want to have a Yealink T-22 change from 1 line to 2 lines, you can execute that change NOT with a site visit to your client, but with the click of a mouse. This dramatically reduces labor and wasted time in client site visits by eliminating unnecessary troubleshooting.  In summary 2600hz has built an awesome suite of provisioning tools for our clients to use in managing their systems. Provisioning is hard because hardware manufacturers make it hard, but that’s why there’s an opportunity for us to innovate in the first place. By concealing complexity from our clients, we make things run smoother and in a much more controllable fashion. See our Powerpoint here: Do provisioning servers make you feel weak in the knees? Does the prospect of reading SIP Packets for a living intrigue you?  You might have a future working with 2600hz. If this is interesting, shoot us an email at [email protected] and we’ll chat :D. [Less]

Expert Q&A Faxing Edition Don’t forget to join us at our next Q&A on Provisioning. Here’s the link: http://2600hzqa3.eventbrite.com/ We wrapped up an excellent Q&A this morning on the subject of faxing. Yes, the Darth Vader of VoIP has ... [More] been slain. We broke down a ton of helpful information in our attached powerpoint and hopefully we were able to debunk a lot of myths. If you missed the event, here are some great quotes: Silence is the signaling protocol for Faxing -Darren Schreiber, CEO, 2600hz Fax machines were designed to deal with noise, not dropouts. IP is designed to deal with dropouts but not noise. The secret to doing faxing at scale is finding the happy medium. -Joshua Goldbard, VP of Marketing, 2600hz We also had some great “Pro Tips” for folks doing faxing at scale: Turn up the Jitter Buffer Turn off the adaptive buffer (Variable timing is death for faxing) Turn off Echo Cancellation (Remember silence is the delimiter) Reduce Confounding Factors (If it doesn’t help, eliminate it so it can’t break later) Finally, one piece of the discussion I wanted to pull out was the talk on codec negotiation. Some carriers will ask folks to start calls as G729 and then change to T.38 midway through the call. The reason a carrier does this is because running calls over expensive gear is expensive. Ideally, a carrier will only run the calls that require expensive gear over the expensive gear and everything else should run over the cheap gear, but the one of the major features of the expensive gear is T.38 tolerance. What this means is that you have to first send a signal to your carrier to get onto the expensive switch (starting the call in G729) and then convert the call to T.38 afterwards. THE REASON CALLS WITH NAKED T.38 FAIL is because many carriers are not setup to route T.38 media unless you tell them it goes on the expensive gear. Therefore, you have to signal G729 first to get on the expensive gear before you can begin a fax transmission. This is a huge pain, but it exists to lower the costs of carrier operations. Last note: Asterisk and Freeswitch both use spandsp so if someone tells you it works better on one platform over the other, they’re probably commenting about the network and not the switch Don’t forget our provisioning Q&A, two fridays from today. Here’s the link: http://2600hzqa3.eventbrite.com/ Thanks and see you soon! Faxing Q and A from Joshua Goldbard [Less]

Visualizing a Cyber Attack on a VoIP server. Really cool visualization! The best part is that the honeypot (the server setup by the security researchers) is not even broadcast to the public internet as a VoIP server. Imagine the scale of attacks advertised servers receive. http://vimeo.com/19997906

2600hz Virtualization Expert Q&A Recap 2600hz hosted a panel this morning on Virtualization in Communications applications. The panel featured expert commentary on OS timing, Lost Ticks, Virtualized hardware demands and best practices in the ... [More] Telecom industry. The panelists were: Darren Schreiber, Co-Founder, 2600hz Adam Kalsey, Product Manager, VoxeoLabs Chris Spearman, Big Data Systems Architect, PSSC Labs Here are some of the highlights from the event: Virtualization for virtualization’s sake is not the right approach. We don’t build database without reason, and even though it’s sexy to do cloud infrastructure, there has to be a business case driving adoption. -Joshua Goldbard, Moderator, 2600hz We see degraded performance on virtual hosts operating near capacity. In our experience, running virtual hosts at 25-30% of capacity will allow them to perform at a similar level to physical boxes. -Adam Kalsey, Panelist, VoxeoLabs For 2600hz, virtualization is about control. It’s impossible for me to provision physical boxes at a remote datacenter via API or with sufficient urgency, but the elasticity of the cloud means response times are consequently lower. Virtualized infrastructure can be much more responsive. -Darren Schreiber, Panelist, 2600hz VIRTUALIZE ALL THE THINGS!! -Chris Spearman, Panelist, PSSC Labs Honestly, I think virtualization makes a lot of sense. I run virtualization on everything because of the backup and retention benefits. Recovering a physical box is not a trivial task, but virtualized instances are easy to maintain and restore. -Chris Spearman, Panelist, PSSC Labs We had a sprited talk about Virtualization and I hope everyone had a blast. We’ll be doing this again in two weeks at our next Expert Q&A on Faxing. Join us here: http://2600hzqa2.eventbrite.com/ Thanks to our awesome panelists and I look forward to talking to all of our attendees in the future. Thanks!! -2600hz Training Team Do you run a VoIP Company? Did you enjoy the training? We’d love to hear your feedback about the event! Email [email protected] with your questions or comments. If you’re interested in speaking on an upcoming panel drop us a line! Once again just email [email protected] and we’ll get you sorted. [Less]

Ivar walked into our office on February 22nd, 2012 and I’ll remember the meeting for a long time. I was sitting there with Patrick and Ivar was telling us about his plans and all of the different things he was going to enable. I have to admit I was ... [More] skeptical, as many companies have tried to enter the space OnRelay plays in and most of them have failed miserably. Mobile phone communications is really hard and I think everyone has seen a company fail in the past. But then, Ivar took out his phone and showed me the product. From that day on, I knew we were going to become partners and I’m tremendously happy to announce the introduction of the OnRelay Mobile Office Phone System, powered by 2600hz. Starting at $9.99 per user per month, OnRelay is offering a robust communications platform that’s truly mobile. It’s an exciting time to work in communications and we’re honored to have been selected as one of OnRelay’s infrastructure partners. The Kazoo cloud infrastructure supports OnRelay’s business and provides the provisioning and communications technology that really reduced their time to market. We look forward to watching OnRelay grow and we anticipate many great things from our partner. Keep an eye on this one, we think it’ll be one to watch in the coming years. -Joshua Goldbard, VP of Marketing, 2600hz PR: http://www.prweb.com/releases/2013/4/prweb10613423.htm [Less]

“Voice and Video are Dead. Here’s the future:” - We at 2600hz believe that the debate over voice and video has been going on for far too long.  People have been dwelling in the past and are conditioned to believe that they have to use mediums like ... [More] voice and video to communicate.  Here at 2600hz we look towards the future.  The time has come when desk phones, cell phones and Web RTC are no longer relevant.  The time when people communicate how they were always supposed to is upon us and it is… TELEPATHY! Telepathy (from the ancient Greek, tele meaning “distant” and pathe or patheia meaning “feeling, perception, passion, affliction, experience”) is the transmission of information from one person to another without using any of our known sensory channels or physical interaction.  2600hz has been putting in a lot of research into understanding how the brains can communicate via a direct connect.  Some people call Telepathy the Bluetooth for your craniums and we couldn’t agree more.  Our engineers have worked diligently to communicate with thoughts vs. words or gestures.  We have made some huge strides with this technology and look forward to releasing it to the world.  We call this project BrainRTC™.We hope you join us on this adventure of truly revolutionizing communications.  Welcome to 26000hz, the “Future of Cloud Telepathy!” [Less]

“Voice Isn’t Dying” - Voice isn’t Dying It seems like everywhere you look these days, someone is killing the voice network. ReadWriteWeb says “Microsoft’s Skype owns 1/3rd of a dying network” and Facebook has a mobile client that now does free ... [More] phone calls, but all of these projects are missing the point. It is precisely this dogmatic approach to annihilating voice that assures the long life of telephony. How? Because the phone network has a few qualities that a company like Facebook will never offer. One of the key features of the phone network is interoperability. If I pick up a phone in San Francisco and call a phone number in Zimbabwe, I know the phone in Zimbabwe will ring. I don’t care what equipment that network operator runs, we both don’t have to be logged into Facebook to connect, and I know that the call is routed over a secure connection that is regulated by the governments. Further, I know that the phone number will route because of the ubiquitous international directory we call the NANP (North American Numbering Plan) which most of the world has adopted, along with e164, both standards. Let’s contrast this with any free voice application. In order to have free calls on a mobile phone, we both have to use the same app and the call is routed over the public internet with best-effort service. If the call drops, no one can be blamed, and if service is out, well, good luck. In fact, when we talk about the idea of interoperability, it is actually antithetical to Facebook’s business, and the business of most application-based telecom companies. What benefit does Facebook derive from interoperating with companies like Voxer? The answer is none and that’s why Voxer lost access to the Facebook API. In reality, the phone network won’t die any time soon because of the ubiquitous address book we call phone numbers, the advantages of interoperability and because of the extremely low barrier to entry. While Facebook may have between 500M and 1B active users, the phone network is many times larger than that (with Cellular penetration exceeding 200% in places like Hong Kong). Facebook is massive, but the telephone network is more massive still. So if Voice isn’t dying, what is changing? A lot of folks argue Voice is dying, but when you get down to the nitty gritty, most of the time what they’re actually arguing is that copper is dying. This very well might be true, especially in light of AT&T attempting to have the FCC relinquish its requirement that AT&T maintain the copper networks in the US. If that happens, the only copper networks that will remain active are those that are profitable, which is certainly not ubiquitous connectivity. At the same time, we perceive fewer folks to be using voice as alternative non-synchronous methods of communication become more common place (SMS, email, etc.). That being said, Synchronous methods of communication, like Phone calls, will continue to exist so long as time sensitive activities are necessary. The market is changing, migrating away from copper, but voice is hardly dying. In fact, part of the perception of lower voice usage comes from the fact that IP communications are much harder to measure, due to the nature of IP. Essentially, companies like Skype and Facebook and all of the other upstarts won’t kill Voice because Voice is a necessary evil. And, let’s be honest, just because the last mile of the connection is turning into wireless doesn’t mean all that core switching infrastructure is suddenly useless. In fact, quite the contrary; that core switching infrastructure becomes many times more important as the quantity of data, and the stochasticity, increases. No, Voice isn’t dying; it is evolving. If talking about Voice Networks and the evolving communications needs of society gets you hot under the collar, we’re hiring! Looking for Senior engineers and Sales folks to help scale out 2600hz, the Cloud telecom company. We’re building amazing Open-Source Telecom infrastructure and changing the world, one call at a time. Join us today!! [Less]

2013 is just getting started and so is 2600hz! We’re proud to announce that we’re the recipients of the Communications Technology ‘Innovator Award’ at DeveloperWeek! We’re also giving away 5 passes to DeveloperWeek starting in February! Here’s how ... [More] you can win a free conference pass ($120 value): TO WIN: Tweet a message with the hash tag #dev2600 and tell us how Technology makes your life better. We’ll pick the top 5 messages and send passes to Developer week!! [Less]