mc_

Crossbar will use the 'Content-Type' header you provide when uploading the media binary data.

Hi @Avneet Singh The files should exist as attachments on the media doc ({MEDIA_ID}) in the account database.

Number states can be read about more here: https://docs.2600hz.com/dev/core/kazoo_number_manager/doc/number_states/ I'm not sure what monster-ui uses to determine "spare" vs "in-use"; @azefiel ?

You can configure the "children" to branch based on the SIP response code. From memory but something like: { "flow": { "module":"resources", "data":{...}, "children":{ "sip:486":{ "module":"menu"... } } } }

The CDR (or channel_destroy webhook) will have the hangup code and cause.

@Josh Robbins Ladder diagrams and MOS scoring are still on the roadmap; I don't have specifics though.

@extremerotary thanks for the report, will discuss at our standup today and see what's up.

@Marie Do you have any request logs of those failed transfers? I'm taking a look on our side but was curious if you had anything collected yet. RE: loading operator console, no issues on our side loading it so not sure where to go from there.

You'll want to take a look at the 'camper' application and its attending callflow action.

@extremerotary its more along the lines of starting a dynamic conference with a custom conference profile (config for moh, alone-sound, etc) and making sure each participant is brought into the conference with the proper configs set. The transfer to the conference FS server should handle CCVs; are you seeing them come in as missing if the caller is moved by Kazoo to the right box?

If you stick to `yum update kazoo-*` you shouldn't have a problem; its the wide-open updates that mess things up.

Hi @tkiziah The installation guide still recommends CentOS 7: https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/ Packaging for Debian was almost complete but there seems to be a few issues left to be ironed out before it can be recommended. That said, I run my dev environment by building all the components from source on Debian so if you are comfortable with that, you can use the install guide but adapt it for Debian. You'll have to do the systemd stuff yourself (if you want it) and some other things but for the most part it works pretty well (for dev; I would not recommend for prod).

Kazoo is tightly coupled to CouchDB

Thanks for the feedback! So, there are two guides that help you get setup with Kazoo: 1. How to install everything on a single server: https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/ 2. A guide on setting up a cluster: https://docs.2600hz.com/sysadmin/doc/kazoo/cluster-guide/ These should be straightforward for a person with sysadmin experience to use to setup a single-server for testing and a cluster for production. We've also had some nice contributions from the community on both docs to improve the experience of setting up Kazoo. After you have a system setup, its a matter of figuring out what you want to do and finding the relevant docs to accomplish that (no small feat in some cases). Most interaction with Kazoo is done via API (or via MonsterUI) or using the SUP command from the CLI. Neither Monster nor SUP require programming skills; however if you want to do something not covered in the Monster apps available, some programming to talk to Kazoo via API will be necessary. We always want to improve the onboarding experience for folks new to Kazoo so please keep letting us know what's not working for you or where you get stuck.

I would add, even within those three groups we see a lot of stratification of needs, desires, and abilities. So while one developer wants to use APIs to build a typical multi-tenant PBX system, another wants to build a custom call center solution using Kazoo as the telephony engine, while another wants to build a trading desk for fintech, while another wants to build some webrtc-based phone thingy and another wants to add telecom features to an existing application. So its usually more helpful to know what you want to do, high level, and point you at the right docs and give basic feedback based on that. We're working on covering the basics but past that it really is choose-your-own-adventure exploration.

The trouble is we have at least three audiences who want to "learn" Kazoo. 1. UI developers - want to know what APIs there are, what they do 2. Core developers - want to hack on the Erlang code, write their own Kazoo applications 3. Sysadmins - want to administer Kazoo properly, configure, tweak settings, etc Each has a start of a documentation site: 1. UI devs can use https://docs.2600hz.com/ui/ for building Monster Apps and https://docs.2600hz.com/dev to see the API reference docs 2. Core devs can use https://docs.2600hz.com/dev as well; plus there is work on generating edoc and getting that integrated into the docs site 3. Sysadmins can use https://docs.2600hz.com/sysadmin to get started All of these are backed by public git repos on Github and thus can be contributed to by anyone. But I don't see a lot of pull requests come into those repos, even when folks get help here on the forums; sure would be nice if they could take their learnings and update the relevant docs to better educate everyone. That said, we do offer a 3-day comprehensive Kazoo training class - primarily targeted at sysadmins for how Kazoo works. I have led Kazoo-Erlang trainings in the past and would like to do another one - we're kicking around ideas of how to make that happen. So you can ask here to learn, you can read the docs site(s) to learn, you can always read the code ;) and you can contact sales@2600hz.com if you want to be part of a paid training course. Oh, there's also a youtube channel: https://www.youtube.com/user/2600hzOfficial We also do a bi-weekly community dev call (just had it today) where you can ask questions; I'm usually on there and others from the team join as they're able.

Hi @Syed Hasan! Most of the docs around the APIs (such as devices) include example cURL commands to get you started. Most languages have HTTP clients so you should be able to start playing with the APIs using your client of choice in your language of choice. I'm not aware of any pre-existing Java SDKs for Kazoo's APIs though. We're obviously happy to help answer your questions if you want to provide one to the community though!

Certainly we need to know these use cases that are failing for you so Kazoo can be more robust in the face of the errors. Mind filing tickets for each of these so we can investigate and get some fixes in? I don't think there's a limit on URL-based files; just that you will see a delay on calls that hit a FreeSWITCH server with a cold cache. Shoutcast streams are a nice alternative as I believe FreeSWITCH will just stream bytes as needed during the call vs fetching the file in full before playing, but providing the stream is a different experience vs providing a file. This is good feedback and I hope we'll see some tickets come in where we can coordinate this work! Thanks

If you change the MP3 at mydomain.com/file.mp3, there is nothing to tell Kazoo that the media changed. I don't think FreeSWITCH will do HEAD requests or use HTTP headers to determine whether to download again. You can upload the media file to Kazoo instead; if you replace the attached MP3 it should cause the media to be flushed from the underlying systems. I can't think of a programmatic way to flush the URL though...

Sponsor-able by anyone. I believe the development rate is affected by whether the work will go into the open source Kazoo project or be a closed source project specifically for you. Contact sales@2600hz.com to get more information on sponsorship and your options there.

Thanks for the alert. Looks like the cert expired. Forwarded to operations.

You can setup a device to auth by IP address by setting the device's "sip.ip" and "sip.method" = "ip".

Appears that RFC 4662 is on the roadmap but no timeline afaict. It is sponsor-able though, so if its the only thing holding you back, that could be an option too.

Hooray! A win for the day :)

You could create a menu that has the password as one branch, going to the page group and a default branch going to a recording. You may have to use the API to set that up as I don't think you can configure menus in the UI with multi-digit branches.