mc_

You can also accomplish this via API: https://docs.2600hz.com/dev/applications/crossbar/doc/voicemail/#change-a-message

I think you will want to check out our architecture page: https://2600hz.com/architecture If you can ask questions using more general terminology instead of AVAYA-specific, that would probably help us find you the answers you're looking for!

@wolfru68 Thanks for the translation I'm not entirely sure but I think the AVAYA concepts map to KAZOO as such: SES(SIP Enablement Services): KAZOO provides SIP connectivity via Kamailio and FreeSWITCH, with KAZOO providing the high level routing logic to those components. So if you stand up a KAZOO instance with all the components (via the install guide as mentioned earlier in the thread) you will be able to provide SIP connectivity (trunking, PBX, etc). ACM (G650) (Aura Communication Manager): Again, appears to be providing SIP services (like PBX functionality). This is built into KAZOO. Typically you will create SIP devices, create numbers and callflows for what to do when the numbers are dialed. The callflow actions are things like IVR menus, routing to devices, users (all devices owned by that user), upstream carriers, playing prompts, directory services, etc. AIC (Interaction Center): As far as I can tell, this is contact center functionality which 2600Hz provides to partners via Call Center Basic and Call Center Pro (the KAZOO app is called Qubicle in case you've seen that name floating around). There is a community-maintained call queues app called ACDc as well. VP(IVR): IVRs are definitely build-able via callflows. You can also use Pivot to make an HTTP request to your server on each call to dynamically build the IVR. Call Center Basic/Pro provide specific prompts for wait time and other announcements when waiting in queue. AES (Application Enablement Services): Basically APIs to control stuff. Yes to all that. KAZOO is built from day-one to be API driven. See https://docs.2600hz.com/dev/ Hope this helps a little?

@Kirill Sysoev can you help @wolfru68 translate this to English? I assume he wants help with KAZOO vs Avaya PBXes (based on Google Translate).

@Noah Mehl has the patch to FreeSWITCH been backported to the version installed alongside KAZOO 4.3? AFAIR the uuid_fileman stuff wasn't working prior to the fix in FS master, no?

@Rick Guyton are you thinking there should be a menu option during playback to read back the caller id number?

@It_panda welcome! You'll want to get a single-server install up first: https://docs.2600hz.com/sysadmin/doc/install/install_via_centos7/ Once you are comfortable playing around with it, check out setting up a cluster: https://docs.2600hz.com/sysadmin/doc/kazoo/cluster-guide/ And of course, if you like, you can contact sales@2600hz.com to see about paid support in setting up and maintaining a cluster too. Feel free to ask questions here in the forum as you encounter things!

Hi @Jim_PGi you might need to make manual calls to the presence API. I'm not sure if this is exposed in the UI though. See https://docs.2600hz.com/dev/applications/crossbar/doc/presence/#reset-presence-state

Take a look at the clustering guide: https://docs.2600hz.com/sysadmin/doc/kazoo/cluster-guide/ I would recommend upgrading to 4.3 and see if these issues persist. If they do, then we can dig into the nitty gritty and figure out if its kazoo, environment, combo, or just gremlins!

As the SSO stuff is still a work-in-progress, the docs are evolving as we go. We have an internal doc for setting it up but there are still a lot of details to work out before it is ready for release to the broader community. Of course, if you are familiar with the SSO flow of OAuth you can probably figure it out but a comprehensive guide is not currently ready for release.

jonny5 is a reference to the movie Short Circuit; the kazoo app tracks limits and balances for accounts and does authorization for resource-consuming calls. In other words, it short-circuits calls that are not authorized :p For numbers, check out https://docs.2600hz.com/dev/doc/internationalization/numbers/ You'll probably want alternative prompt languages too: https://docs.2600hz.com/dev/doc/internationalization/prompts/ While most of the 2600Hz team is US-based we do have a number of devs outside the US as well as a group of community members outside the US too. We all want KAZOO to be a proper platform for any region of the world. That said, we also know we have blind spots of how telecom is done everywhere so any feedback you have which can be incorporated into the project for everyone to take advantage of, is greatly appreciated. Also, when you feel you need to look at code or the docs aren't sufficient, ask here in the forums - that's usually a good trigger for someone to take a stab at improving the documentation. You are always welcome to submit PRs for improved docs as well.

You can create ring_group callflows with just the devices you want to ring. Instead of including the user's ID, include the SIP device's ID in the ring_group.

Please define more specifically what "drop the call" means. Did the device answer then hangup? What's the SIP response code/reason? "Drop" is unfortunately too ambiguous.

If the first device answers the call, then the ring group is effectively over. What exactly are you seeing from the first device?

For support, free options include this forum and IRC; you can email sales@2600hz.com to see about dedicated support plans. For open-source builds you are probably best served with the 'dev' docs site: https://docs.2600hz.com/dev/ Also the 'sysadmin' docs site: https://docs.2600hz.com/sysadmin/ Both are great places to contribute to the project if Erlang code isn't something you want to take on at the moment.

Account specific, you can create a callflow with the "patterns":["908205\\d+"] and the 'respond' callflow action. You could create a number classifier for "blocked" numbers that would be available across accounts. You can blacklist numbers (not sure on regexp but if the number of DIDs isn't large it should be fine).

You "use" DIDs by assigning them to an account and creating a callflow in the account to run when receiving calls for the DID. There are no zone restrictions on that.

To elaborate: Within a zone (generally a data center), you define the AMQP URL of the primary broker in the config.ini file. This URL can be a single instance of RabbitMQ or it could be HAProxy (or whatever) that sits in front of a clustered RabbitMQ (2+ servers). To Kazoo, it is still one logical broker. You can also (or instead of) define a secondary AMQP URL (and tertiary etc) that will be used if the primary AMQP broker goes down.

@thanhnn.ict you might want to look at putting those in the sipinterface_1.xml instead. Just in case you decide to run multiple SIP interfaces that may not use the same external IPs.

I believe rating will debit via ledgers but things like auto top-up and such use transactions

1. There is no timer mechanism for auto-logout - you can file a feature request. 2. AFAIK when you fetch the device via API, it will include the user ID(s) who are hotdesked into that device. 3. Not sure what this would look like since a device can potentially have more than one user hotdesked. You can file a feature request to debate possible approaches

Check /opt/kazoo/lib for a jonny5 folder. If it doesn't exist, see if 'yum install kazoo-application-jonny5' works

I think you need to use `ledgers` for "funny money" and transactions for "real money" stuff.

Pivot expects to be in control of the call once the pivot callflow action is executed. This may mean sending the response callflow JSON back to the callflow executor, but the intent was never to let the response "inject" callflow but to "be" the callflow going forward. Kazoo UI was thus coded to have the pivot action be a terminal action and not allow children. Some time after Advanced Callflows was ported from Kazoo UI to Monster, the ability to have a "failure" child on the pivot callflow was introduced in case the HTTP request failed or the response was invalid. I think Darren mentioned that Advanced Callflows is close or on the roadmap for a refresh so I would wager this failure child will be doable via the UI once that's complete.

Kazoo sets the Content-Type header in the response to the mime type of the binary data. Typically it will be "audio/wav" or "audio/mp3" but will depend on how the audio was uploaded.