mc_
-
Posts
1,766 -
Joined
-
Days Won
4
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by mc_
-
-
Don't think so, offhand. There's a 'set_audio_level' FS command that could be useful? If you want to try it out and let us know, we can look into incorporating it
-
As far as I recall, KAZOO has some facility for coverting wav<->mp3 but that is rudimentary and I think only for uploading media through the API. Your best bet is to fetch the recording and convert it on your server.
-
You'll likely need to tinker with FreeSWITCH settings; I'm not sure if alternatives are supported though. Probably post-recording format conversion will be needed.
-
A basic intro to the API and setting up devices and carriers: https://docs.2600hz.com/sysadmin/doc/install/configure_kazoo/
From there, check out the bigger collection of Voice APIs: https://docs.2600hz.com/dev/
KAZOO does not have LCR capabilities, just basic ratedeck support. Most folks setup LCR servers as a carrier for KAZOO to route through when needing that functionality.
-
KAZOO does not do outbound registrations, meaning it will not register to your peerless account.
One way would be to create a "device" in KAZOO to represent the peerless system and have peerless register to KAZOO (if possible). That would allow extension dialing.
You can also create peerless as a carrier in KAZOO and accept inbound calls from it (peerless IP(s) need to be in the ACLs); but you would need to setup E164 numbers on your callflow. So a little more complicated but would set you up to accept traffic from other carriers as well.
-
You'll need to investigate the db side (maybe check HAProxy logs too). Is couch on a public IP? Maybe someone is messing with you?
Check kazoo logs, make sure you aren't inadvertently deleting the account through some automation gone wrong.
-
Yeah we currently have to deploy those apps to trusted environments to prevent piracy. The app exchange will include a distribution mechanism to handle this better.
-
You can also find out more here: https://forums.2600hz.com/forums/home/
-
The plan is to re-open-source all the applications and core that 4.3 currently has (so apps like Crossbar, Teletype, Ecallmgr, etc).
One lesson from the 3.22->4.0 upgrade we learned was people will try the new stuff before its officially ready, encounter issues and complain, and revert back to 3.22.
The other complaint is that we want to address is from open-source folks wanting to purchase our closed-source apps (like our call center app qubicle). Due to the nature of how the Erlang VM works, this isn't really do-able via "rpm install" methods.
So we've taken more time to develop 5.0 behind the scenes so folks don't start using it and lose confidence before it even has a chance. We've been upgrading our clusters with it to iron out upgrade-related bugs, accidental backwards incompatibilities, and the like. Concurrent with all this is the app exchange and a mechanism to deliver closed-source apps like qubicle to open-source clusters.
-
Not currently. We've rolled 5.0 out to our hosted platform and select customers to iron out the technical challenges with 4.3->5.0 upgrades. The app exchange is in active development, which I believe is the last component to the release of the open-source components of KAZOO.
-
Is the system_configs endpoint enabled? Its off by default
-
@huwsc90 Hi!
One guess is that the auth-by-ip information has left the cache and has to be pulled from your database. This process is delayed long enough that the reorder app's response of Nope Nope Nope is received first. Subsequent calls then work as expected as the cache is primed.
Compare logs of the first call that fails against the subsequent call that succeeds to see where the slowdown might be (thinking stepswitch_inbound and related processing to resolve IP to account).
-
I'm trying to get an "official" doc on this but my understanding is 2600Hz and Signalwire have agreements to let 2600Hz distribute the newer versions of FreeSWITCH with KAZOO but that Signalwire releases the source on a delayed basis. Something to that effect, anyway. So yes, packages from us will reflect more recent work in FreeSWITCH than is available via their github.
When I have an "official" doc, I'll get it posted here for everyone.
-
Yeah, there are a number of ways to do it. Most use the e164 converters; see https://docs.2600hz.com/dev/doc/internationalization/numbers/#converters
-
In KAZOO, a "dialplan" allows configuring ways to adjust the dialed number. For instance, in the US of A, you could dial a local number without the area code; with dialplans, KAZOO can adjust that 7-digit dialed number to the full 10-digit (or full E164) version before Callflows processes it. But dialplans are not a "typical" feature folks tend to use.
-
404 on your link so just in case: https://docs.2600hz.com/dev/doc/internationalization/numbers/
I think your sentence-ending period got linked as well, throwing off the URL.
If you have used FreeSWITCH before, KAZOO doesn't use the dialplan XML - every call is handled in real-time by KAZOO. The primary call processing app is named 'Callflows'.
From an API perspective: https://docs.2600hz.com/sysadmin/doc/install/configure_kazoo/
You should get a device, number, callflow, and resource setup and make calls using that.
If there are specific parts of the docs that don't work for you, you can use the Edit (pencil icon) which should bring you to the github repo that backs these doc sites if you have suggestions. If a command fails, please include the command tried and the output; we can help see if the docs are wrong or your invocation.
-
Resources do not register to upstream carriers, as this would break the resiliency of the platform for that carrier. Most carriers allow you to specify a list of IP addresses to deliver calls to (should be your Kamailio IPs). If the carrier you are using requires registration, there are some old old instructions floating around to setup a FreeSWITCH config to force the registration to proxy through one of your Kamailio servers. Or you can setup a vanilla Kamailio to register to the carrier and setup your vanilla Kamailio as a "resource" in KAZOO.
You'll find the "resources" API here: https://docs.2600hz.com/dev/applications/crossbar/doc/resources/
Suggestion that you don't manipulate the CouchDB databases directly; the API server code (Crossbar) does a lot of things in addition to accepting API requests and putting them into the database. The handful of things that do require db access are typically one-offs, set it and forget it type things.
And welcome! We're always open to improved docs if you have suggestions and PRs! Let me know when you want to start learning Erlang too ;)
Oh, and if an API doesn't seem to work, make sure it is running on the API servers: `sup crossbar_maintenance start_module cb_resource_selectors` for instance. Just prepend "cb_" to the API endpoint's name for the Erlang module to initialize. This should add it to the list of modules to start as well.
-
Please verify what version you installed. The last time "whapps_controller" was a thing was...years ago.
https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/
-
-
Something is amiss, then, as the channel bindings are put on the 'webhooks_shared_listener' which uses a named queue, shared by all instances of the webhooks app.
The bindings are not federated so other zones should not be receiving copies either.
So my guess at this point is you have two webhooks configured and enabled for the same HTTP server, causing the duplication.
-
PRs to https://github.com/2600hz/kazoo-sounds/tree/master/kazoo-core
Would be great to improve the prompts available to all KAZOO users!
-
Not seeing the crash in kz_hooks_util though, so that's good! But yeah it does appear that konami decides to exit after the bridge occurs. Hopefully the community can patch the behaviour to correct this!
-
@Marcin Muzylo the patch was applied 4 months ago: https://github.com/2600hz/kazoo/blob/4.3/core/kazoo_events/src/kz_hooks_util.erl#L144
Can you get the new crash / stacktrace?
-
"direction" will be relative to FreeSWITCH so "inbound" means a user agent started the SIP dialog (aka FreeSWITCH received the initial INVITE) while "outbound" means FreeSWITCH is initiating the comms (aka FreeSWITCH sending the initial INVITE).
I believe the CDRs API will return user-specific CDRs using /v2/accounts/{ACCOUNT_ID}/users/{USER_ID}/cdrs: https://docs.2600hz.com/dev/applications/crossbar/doc/cdrs/#variations
Call recording has its own API: https://docs.2600hz.com/dev/applications/crossbar/doc/recordings/
Voicemails are under the vmboxes/{BOX_ID}/messages: https://docs.2600hz.com/dev/applications/crossbar/doc/voicemail/
No grand unified APIs; each API is focused on the collection or entity described, generally speaking.
copy of couchdb every first of the month
in Product Discussion
Posted
These are MODBs: https://docs.2600hz.com/dev/core/kazoo_modb/doc/
They are critical to KAZOO usage, so there's no disabling of them. If the MODB doesn't exist when a document (like a CDR) needs to be saved, the MODB will be created. If you have a lot of activity, they'll all stack up waiting for the MODB to be created.
What you can do is configure the MODB task (https://docs.2600hz.com/dev/applications/tasks/doc/modb_creation/)
Set that to pre-create the next month's MODB for all accounts and give it enough lead time (say 3-5 days depending on how many accounts you have); the task will automatically spread out the MODB creations across that time period to hopefully minimize impact on the DB cluster.