Kazoo API completeness

[A E G]

Hello Kazoo-ers

quick question about the Kazoo API. It may seem a little open-ended but would the creators/devs of the Kazoo platform (or if users in the field actively using it in production or development want to chime in) say that the Kazoo API is reasonably complete at this point and that anything that can be done directly interacting with FreeSWITCH via mod_event_socket or xml_curl etc can be achieved by developing against the Kazoo API? Not planning anything totally out of left field but say a reasonably complex IVR. No PBX functionality required.

Sorry, if this is one of those ridiculous questions that you hear once in a while on mailing lists.

Cheers

[Darren Schreiber]

Hi there,

I don't like to compare the two directly as there are uses for stand-alone FreeSWITCH and uses for Kazoo that don't line up 100%. That said, I can understand the desire to see progress and what features in FreeSWITCH are accessible currently.

I'm not sure there will ever be a 1:1 translation. Our goal is distributed telephony. So I will list what I believe is "similar enough" to warrant calling complete below. To be clear, there are significant differences between the way we've implemented, or redesigned/mimic'd, many of the built-in FreeSWITCH modules and some we just use outright. Hope this helps.

Fully Implemented/Supported

mod_logfile <-- see /var/log/2600hz-platform.log

mod_syslog <-- see /var/log/2600hz-platform.log

mod_cdr_csv <-- cdrs (go into DB by default)

mod_sofia

mod_loopback <-- our version

mod_conference

mod_db <-- hmm well, couch? I guess this counts

mod_voicemail <-- our version

mod_directory <-- our version

mod_distributor <-- our version

mod_spandsp <-- includes fax capabilities

mod_g723_1

mod_g729

mod_amr

mod_ilbc

mod_speex

mod_h26x

mod_siren

mod_isac

mod_celt

mod_opus

mod_sndfile

mod_native_file

mod_shell_stream

mod_shout

mod_local_stream

mod_tone_stream

Implemented but Not Documented

mod_xml_curl <-- pivot

mod_httapi <-- pivot or AMQP messages

mod_xml_cdr <-- webhooks CDR

mod_dingaling

mod_freetdm

mod_rtmp

mod_fifo

mod_lcr <-- "hotornot"

mod_valet_parking

mod_flite

mod_cepstral

mod_nibblebill <-- "jonny5" limiter

mod_callcenter <-- call queues

Not Implemented but Pending

mod_console <-- working on this (platform_status.sh)

mod_snmp

mod_ldap

mod_portaudio

mod_esf

mod_spy

mod_dialplan_xml <-- ability to insert random XML snippets

Won't Implement

mod_enum <-- no plans, is this popular? nobody ever asks

mod_fsk

mod_snom

mod_pocketsphinx

mod_tts_commandline

mod_rss

mod_dialplan_directory

mod_dialplan_asterisk

mod_fsv

mod_spidermonkey

mod_perl

mod_python

mod_java

mod_lua

mod_cluechoo

mod_openzap

mod_unicall

mod_skinny

mod_alsa

mod_woomera

mod_xml_rpc

mod_yaml

mod_cdr_sqlite

mod_event_multicast

mod_event_socket

mod_event_zmq

mod_zeroconf

In Addition to FreeSWITCH, These Pre-Built Modules Exist…

Full API set for configuration

Full API set for call control

Database manager & compacter

AMQP message bus support

WebSockets event streaming

Distributed Registrations

Time-of-Day

Provisioning (via Andrew Nagy's provisioner.net scripts)

Number Management / Number Inventory

Multi-tenancy APIs

Server Management APIs

User Portal

PBX Trunking / SIP Trunking

DISA

Manual Presence (trigger lights by dialing things)

Dynamic Caller ID

Hot Desking

Hope that helps.

--

CEO / Co-Founder

 visit: www.2600hz.com

 sip:dar...@2600hz.com

 tel: 415-886-7901

[A E G]

Hey Thanks Darren,

Thanks SO much for completely answering the question. I was expecting like a 2-3 line response. This helps a LOT. 

- Love "hotornot" haha. 

- "jonny5"? Is this a better nibblebill? Didn't you write nibblebill? 

- ENUM might be useful, I'm still trying to think of ways to use it in our design, but haven't given it enough thought. I guess it relies on other people registering with the ENUM databases or one could pay some company that has a well-populated database. 

- I'm assuming the mod_<language> aren't / won't be done since the Kazoo API handles any language you want to write your web-app in?

- All the pre-built modules sound great. 

Unfortunately I don't know enough about Kazoo yet to comment on most of the other stuff. Couple of unrelated questions (I'm sure someone will b*tch at me for hijacking my own thread):

 - Do you know if throwing the Kazoo/2600Hz platform on the cloud managed using Rightscale (or similar i.e. Scalr, Enstratus, Cloudify etc) should be any different than managing any other cloud deployment through them? or is that not required?

 - Does the PBX Connector app (or should I say WhApp) connect Kazoo to any box that can handle SIP? If I do my own Kazoo on some cloud provider and spin up an instance of something that can talk SIP, configure that through PBX Connector and go or is there "Some assembly required"?

Thanks much. I can copy/paste the above two questions in a different email to keep it sanitary?

[Darren Schreiber]

See below. Many opinionated answers follow.

 

From: 2600h...@googlegroups.com [mailto:2600h...@googlegroups.com] On Behalf Of A E G
Sent: Friday, August 31, 2012 11:19 AM
To: 2600h...@googlegroups.com
Subject: Re: Kazoo API completeness

 

Hey Thanks Darren,

 

Thanks SO much for completely answering the question. I was expecting like a 2-3 line response. This helps a LOT. 

- Love "hotornot" haha. 

> James named that. J

 

- "jonny5"? Is this a better nibblebill? Didn't you write nibblebill? 

> “Better”? Hmmm I hate better/worse arguments. Different? Yes. J It short-circuits calls when there is no credit or flat-rate services available for them. It’s more intelligent and less flexible then nibblebill, because the logic is pre-programmed. That said, it could be MORE flexible then nibblebill because it can be extended. So, guess it depends how much work you want to put into it. If you just want “out-of-the-box” limits, then this is better than nibblebill.

 

- ENUM might be useful, I'm still trying to think of ways to use it in our design, but haven't given it enough thought. I guess it relies on other people registering with the ENUM databases or one could pay some company that has a well-populated database. 

> My issue with ENUM remains that, ironically, peer-to-peer audio quality and services aren’t necessarily better (surprisingly) then PSTN calling services, and there is overhead in maintaining the accuracy of the ENUM filings. I’m undecided if this is worth it J

 

- I'm assuming the mod_<language> aren't / won't be done since the Kazoo API handles any language you want to write your web-app in?

> The Kazoo API can make HTTP call-outs to your web server and then you can write in whatever language you want, so yes, it seems redundant to me so we don’t support it. We also give you a “mod_event_socket” equivalent (in my eyes) cause you can go direct to the AMQP bus.

 

- All the pre-built modules sound great. 

> Thanks J

 

Unfortunately I don't know enough about Kazoo yet to comment on most of the other stuff. Couple of unrelated questions (I'm sure someone will b*tch at me for hijacking my own thread):

 - Do you know if throwing the Kazoo/2600Hz platform on the cloud managed using Rightscale (or similar i.e. Scalr, Enstratus, Cloudify etc) should be any different than managing any other cloud deployment through them? or is that not required?

> If it’s Linux-based it should work. I think ;-) That said we have a release process that’s CentOS centric at the moment. WE’re welcome to have other maintainers help out expanding the horizons on that.

 

 - Does the PBX Connector app (or should I say WhApp) connect Kazoo to any box that can handle SIP? If I do my own Kazoo on some cloud provider and spin up an instance of something that can talk SIP, configure that through PBX Connector and go or is there "Some assembly required"?

> Yes, in theory, that’s the idea anyway.

 

Thanks much. I can copy/paste the above two questions in a different email to keep it sanitary?

> This is sane enough J  It’s general feature assessment. Seems relevant, though thanks for being respectful on the list. Always nice to see.

[A E G]

Thanks again for the comments Darren. I don't want to take up too much of your time so will keep my comments specific. Inline..

On Fri, Aug 31, 2012 at 3:07 PM, Darren Schreiber <dar...@2600hz.com> wrote:

See below. Many opinionated answers follow.

 

From: 2600h...@googlegroups.com [mailto:2600h...@googlegroups.com] On Behalf Of A E G
Sent: Friday, August 31, 2012 11:19 AM
To: 2600h...@googlegroups.com
Subject: Re: Kazoo API completeness

 

Hey Thanks Darren,

 

Thanks SO much for completely answering the question. I was expecting like a 2-3 line response. This helps a LOT. 

- Love "hotornot" haha. 

> James named that. J

 

- "jonny5"? Is this a better nibblebill? Didn't you write nibblebill? 

> “Better”? Hmmm I hate better/worse arguments. Different? Yes. J It short-circuits calls when there is no credit or flat-rate services available for them. It’s more intelligent and less flexible then nibblebill, because the logic is pre-programmed. That said, it could be MORE flexible then nibblebill because it can be extended. So, guess it depends how much work you want to put into it. If you just want “out-of-the-box” limits, then this is better than nibblebill.

I apologize. Yes different is what I meant :P Or what I was really thinking was that if you did write nibblebill and now you have jonny5, I'm sure the only reason could be either it's built differently i.e. modular/extensible etc. or perhaps tackles the problem differently. Unfortunately I don't have first hand experience using nibblebill so don't know which one is better for my purposes but I do need an intelligent, extensible and flexible module (although I could do an either / or on Intelligent/Flexible to handle some "weird" pre-paid scenarios. Might have to look at both. While I don't have a deep knowledge of the Kazoo architecture, I won't assume that "jonny5" is something that could be made into a mod_jonny5 we can build for FreeSWITCH by ourselves should it turn out that we're not ready for Kazoo yet?

 

 

- ENUM might be useful, I'm still trying to think of ways to use it in our design, but haven't given it enough thought. I guess it relies on other people registering with the ENUM databases or one could pay some company that has a well-populated database. 

> My issue with ENUM remains that, ironically, peer-to-peer audio quality and services aren’t necessarily better (surprisingly) then PSTN calling services, and there is overhead in maintaining the accuracy of the ENUM filings. I’m undecided if this is worth it J

 

Exactly. It requires too much participation from all people I think, and the only people who will do this actively is geek-o-ramas like the ones of these mailing lists. The only other option is companies that have access to these databases that run security/background check/reverse number lookup kinda services to allow an operator to buy API access into their db to build an ENUM formatted db for us to use. Sounds like a complex process but something that could be "kickstarted"/crowdsourced from the Telephony FOSS community.

- I'm assuming the mod_<language> aren't / won't be done since the Kazoo API handles any language you want to write your web-app in?

> The Kazoo API can make HTTP call-outs to your web server and then you can write in whatever language you want, so yes, it seems redundant to me so we don’t support it. We also give you a “mod_event_socket” equivalent (in my eyes) cause you can go direct to the AMQP bus.

Ok, I have absolutely no idea what or how that works. I don't know anything about these message passing queues. But by the sound of it, AMQP bus sounds like this what connects Kazoo to FreeSWITCH, and one could effectively "tap" into the bus directly to control/manage FreeSWITCH? If so, then what is the format? Like I said, I have limited knowledge of the Kazoo architecture but I thought Kazoo and FreeSWITCH talked using erlang and AMQP was between Kazoo layer and the CouchDB. Did I get that wrong? I should probably look this up and not waste your time

 

 

- All the pre-built modules sound great. 

> Thanks J

 

Unfortunately I don't know enough about Kazoo yet to comment on most of the other stuff. Couple of unrelated questions (I'm sure someone will b*tch at me for hijacking my own thread):

 - Do you know if throwing the Kazoo/2600Hz platform on the cloud managed using Rightscale (or similar i.e. Scalr, Enstratus, Cloudify etc) should be any different than managing any other cloud deployment through them? or is that not required?

> If it’s Linux-based it should work. I think ;-) That said we have a release process that’s CentOS centric at the moment. WE’re welcome to have other maintainers help out expanding the horizons on that.

Ok first a disclaimer: I haven't ever played with any of these management platforms but am exploring them currently. So everything I say could have "assumptions" based on extrapolation and derivation from what I know so far. 

So, I don't think it cares but yes, I believe it is. It hooks into the cloud provider's API. So I would assume that the cloud instances on which all pieces of the Kazoo platform are running will look like any other instance to it. Don't think it will care what's running on those instances. But here's the more interesting part of it. It fundamentally uses Chef and it theoretically it could be possible that it can integrate or handle the Chef recipes used to deploy/manage Kazoo. By a similar inference, I won't be surprised if it can let you use your own Chef server along with it. I think I might have answered my own question. I will look into this and see if we can build this integration and give it back to the community if you guys don't get to it first :)

 

 - Does the PBX Connector app (or should I say WhApp) connect Kazoo to any box that can handle SIP? If I do my own Kazoo on some cloud provider and spin up an instance of something that can talk SIP, configure that through PBX Connector and go or is there "Some assembly required"?

> Yes, in theory, that’s the idea anyway.

 

Thanks much. I can copy/paste the above two questions in a different email to keep it sanitary?

> This is sane enough J  It’s general feature assessment. Seems relevant, though thanks for being respectful on the list. Always nice to see.

 

Thanks for the acknowledgement :) respect and desire to help is the only thing that can build awesome free products and sustain a thriving  FOSS community against these 800-lb gorillas :)

But while we're at this "general feature assessment" :P....actually no I'll be polite, I'll start another thread for this other thing I was going to ask.

Thanks so much again