Jump to content

mc_

Administrators
  • Posts

    1,795
  • Joined

  • Days Won

    4

Everything posted by mc_

  1. 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).
  2. Kazoo is tightly coupled to CouchDB
  3. 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.
  4. 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.
  5. 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.
  6. 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!
  7. 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
  8. 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...
  9. 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.
  10. Thanks for the alert. Looks like the cert expired. Forwarded to operations.
  11. You can setup a device to auth by IP address by setting the device's "sip.ip" and "sip.method" = "ip".
  12. 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.
  13. Hooray! A win for the day :)
  14. 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.
  15. AFAICT Kamailio supports RFC 4662 (https://www.kamailio.org/w/interoperability/) So Kazoo should support it or adding support should be straightforward. Can't speak authoritatively on that though; have you tried it?
  16. Perfect! Thanks
  17. OK, mind filing a feature request in JIRA?
  18. If on your own system, you can configure the minimum and maximum recording time in system_config, see https://docs.2600hz.com/dev/core/kazoo_voicemail/doc/README/#system-config-settings I'm not sure what the hosted system's setting is; you could file a support ticket to find out.
  19. Community-supported call queue app is acdc - open source, free to use on your own installation. Qubicle is our paid call center application. There is talk of a "lite" version being free to use / open source but nothing available yet. When the app store is ready, there will be a way to purchase Qubicle for self-managed installations.
  20. Please open a new thread and include logs related to the registration attempt, how you created the device and callflow, and anything else that might be relevant.
  21. Awesome! Good to hear...
  22. Jonny5 needs to be turned on and authz enforced in ecallmgr to get rating of a call going.
  23. You can do this using a combination of Pivot and the "set_cid" callflow action. You could also look at the "check_cid" callflow for branching based on the caller id name; if set as a preflow, that might actually work as well without having to call out to a Pivot endpoint.
  24. mc_

    FaxBox

    Not that I'm aware of. Could be a nice enhancement to the branding app / notification templates. You can file a feature request at https://tickets.2600hz.com
  25. You can check out the repo to get started: https://github.com/2600hz/monster-ui-csv-onboarding
×
×
  • Create New...