mc_

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?

Perfect! Thanks

OK, mind filing a feature request in JIRA?

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.

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.

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.

Awesome! Good to hear...

Jonny5 needs to be turned on and authz enforced in ecallmgr to get rating of a call going.

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.

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

You can check out the repo to get started: https://github.com/2600hz/monster-ui-csv-onboarding

You have the idea that a member can affect their own settings while a moderator can affect others. You can also set up conferences to start/end when the moderator joins/leaves.

I've passed the lack of us-central onto OPS to see if they can get something setup. Thanks for the update!

PRs are always welcome to fix this, of course. I would venture that its not a common configuration nor should it be encouraged but if its a real need, please issue the appropriate PRs to make it happen!

Kazoo is API driven so I suppose if the IMS environment has a way to write adapters to talk to Kazoo it should be possible. Do you have a system in mind?

You'll want to take a look at the logs for Kamailio and FreeSWITCH; I bet something will pop in the logs for what's going on.

If you are hearing a recording it is enabled but didn't find any matching channels.

@Mike Montgomery From reading the list, everything not Qubicle-related is in the open source project.

@FASTDEVICE this won't be possible since you won't be able to create the "internal" number properly. If you create it on the hosted platform, it gets tagged as a "local" number; as such, it would be forced outbound to the carrier, even though it exists on Account B's callflow. This prevents accounts from stealing numbers that don't belong to them and receiving calls for those numbers. Is there a reason why account B's callflow can't have a proper DID that account A can call? As mentioned previously, that DID will not go to the carrier if it has been properly purchased and configured.

So when a call goes to the "Resources" callflow action, stepswitch (the app) figures out what carrier(s) to send the call to, right? But first it checks that the dialed number is not already existent on the system; if the number is found and it isn't forced offnet, stepswitch will hairpin the call back into the system for processing. So any numbers known to the Kazoo system will stay local unless forced to go out. So you could define an "internal" prefix of "+abc" and when you create your callflows, you create an "internal-to-kazoo" DID for that callflow as well. Now your Pivot app returns {"module":"resources", "data":{"to_did":"+abc1001"}}. Since you setup Account B's callflow to include "numbers" :["1001", "+abc1001"], and "+abc1001" is in the number database, stepswitch will hairpin the call to Account B. This is a hack! But if you accept the headache of managing this, it could be a way to accomplish your goal. caveat emptor

Not really. Most operators still bill account A for calling account B, even if the call doesn't leave the system. You might assign "internal" DIDs to your accounts' callflows that you track (that aren't route-able); since you track them you could "dial" "abc123" to route to account A's "123" callflow? Hacky but....

Basic idea is here: https://docs.2600hz.com/dev/core/kazoo_auth/doc/oauth/#using-google-drive-for-voicemails Doc needs cleanup to render better though. Use https://github.com/2600hz/kazoo/blob/master/core/kazoo_auth/doc/oauth.md

A couple quick thoughts I had: Branch based on caller id - presumably internal calls will have internal CID (3-5 digits typically). Branch to user->voicemail. If CID is longer branch to voicemail. Assign two extensions - a "public" and a "private". So internal callers know to dial 5xxx and external callers get 4xxx (or whatever scheme makes sense).

Actually, I wonder if you could route based on the caller ID first. Then you can encode the Time-of-day route to match what the allowed calling times are for each device/user.

Can you give me a concrete example of what your dial_plan is, the number dialed, and your callflow configs?