mc_

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.

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.