mc_

@fmateo05 hope its more of a temporary break But if not, wish you well and thank you for all you've contributed! You're always welcome here.

Appreciate it @esoare !

Hi @naveed6865 can you please start a new post (it appears like you're thread-jacking unintentionally). Please use the search facility as well as I believe this question has answers. If not, please make a new post! Thanks

Please provide a specific question that illustrates your confusion, as what you've written (at least to me) is too vague. You can also check out the Youtube page: https://www.youtube.com/c/2600hzvoip/videos Lots of videos being added around MonsterUI app usage.

Everything about this log suggests it hung up. Check the FreeSWITCH logs to see if it generated the SIP BYE?

Where are you trying to set defaults? In provisioner or via KAZOO API or?

Map the softkey to a callflow with https://docs.2600hz.com/dev/applications/callflow/doc/group_pickup/

https://docs.2600hz.com/dev/doc/internationalization/numbers/ https://docs.2600hz.com/dev/applications/crossbar/doc/resources/ You can setup the resource "rules" to regex-match the types of numbers to route, or you can create classifiers and setup resources to route based on classifiers. Those are two paths I'd look into.

@Kirill Sysoev you live!!! Tell me more about potatoes on KAZOO? Are they in vodka form? And I agree, the platform is becoming more general purpose for building apps that can leverage the scaling bits in KAZOO. Almost borg-like...

It is done! Community-supported apps can be found here: https://github.com/kazoo-community 2600Hz-supported apps can still be found here: https://github.com/2600hz Look for kazoo-{APP} repos like kazoo-crossbar. The kazoo repo itself still serves as the focal point for pulling in core and apps, tooling, CI, etc. Changes to the Erlang code will be committed to the individual repos. There's still a lot of work to do (like linking changes in two or more repos) and general workflow improvements, but this is an exciting step! Plus I may never get a commit stat like '+490 −717,630' again!

Not sure what OSes will be targeted. I think CentOS7 will continue and hopefully a Debian variant. Not sure on timeline for CentOS8 though...

@btracht00 hmm, didn't know there were 3.22 still active lol We weren't planning on keeping the 3.x->4.x migration stuff in there with 5.x so I would say you'll need to upgrade to 4.x first, then 5.x once its available in the packages.

Hi Folks, Its finally happening! We are separating the KAZOO git repository into multiple repos, one for each kazoo application (and one for kazoo core libs). This Friday, May 1st, at the end of business hours Pacific time, all remaining pull requests will be closed from the main kazoo repo (the Erlang team here will be working hard to merge as many before that time). Closed PRs will be asked to be re-opened against the appropriate repo(s) starting on Monday. The breakening will occur over the weekend. The workflow for KAZOO development will be a little different in the bootstrapping phase - you will define the applications you want to include (crossbar, callflows, whatever) and they will be fetched just as we fetch 3rd party dependencies now. The apps will still live under applications/ so most existing tooling will continue to work as expected. We realize there will be some pain points in the transition. We want to hear what you're butting up against so we can build tooling or refine process to make development a more pleasant experience. Community apps like ACDc and Konami will be moved to a new Github organization: https://github.com/kazoo-community If you would like to be added as a contributor or maintainer of a repo under that organization, let me know. Eventually we'll get a proper organizational structure but for now, the leading community contributors are going to be auto-accepted if they ask to be included on those repos. What that means is 2600Hz will no longer be in the mix for reviewing/merging pull requests. The community around each app will be able to move forward as they see fit. This is a big step and we know there will be a period of adjustment for everyone, 2600Hz engineers included. If you have further questions, please ask here and I'll clarify as necessary. Thanks!

Those apps just create callflows using the 'menu' action. Use the children object to match DTMF inputs. See https://docs.2600hz.com/dev/applications/callflow/doc/menu/

I think you want to set the forwarded device's call_forward:{keep_caller_id:true} (assuming you're doing the forwarding server-side. Then look in your system_config's kazoo_endpoint doc for "should_add_diversion_header" and set it to true. `sup kapps_config set_default kazoo_endpoint should_add_diversion_header true` should work. See if the carrier likes that.

@Matrixdz2002 As @mat1010 points out, you can use the "rules" regular expressions to filter what types of numbers can be routed using a particular resource (carrier). See https://docs.2600hz.com/dev/applications/crossbar/doc/resources/ There's also a 'resource selectors' option: https://docs.2600hz.com/dev/applications/crossbar/doc/resource_selectors/ contributed to the community. May help you too (though I haven't personally used it). That should cover the "destination" portion of your question. For caller ID, you would need to setup the callflow(s) with branching based on the caller ID: https://docs.2600hz.com/dev/applications/callflow/doc/check_cid/ Using the match/nomatch branches, you could then use the "resources" callflow action and set an outbound_flag "use_c" or whatever, which the resource doc would need to have in its "flags" as well. See https://docs.2600hz.com/dev/applications/callflow/doc/resources/

wss://sandbox.2600hz.com:5065

I suspect you need to find out what is using the number, no? The number should have a "used_by" attribute that can hint at it. Or search your callflows. Did SmartPBX get opened on the account and auto-create them and you don't realize it?

@Ken Rowland it is my expectation that using the 'set_variables' callflow action with '"data":{"custom_application_vars":{"my":"secret"}}' will cause all subsequent call events for this call leg to include '{"my":"secret"}'. If you add '"export":"true"` then the bridged call leg should also carry them. If that's not the case, please open a support ticket so we can investigate. But we do have customers that rely on these CAVs being present and, AFAIK, we have not received additional reports of missing CAVs.

@simonp22 No not yet, sorry. It is not forgotten, just keeps getting trumped by other work. I'll throw this into the engineering pool and see if anyone else has spare cycles to look too. Otherwise I will try to get to it this week.

This guy's blog is great in general for SIP stuff but specifically https://andrewjprokop.wordpress.com/2013/09/23/lets-play-sip-tag/

I believe msg_id for call events is the timestamp from FreeSWITCH, at least in 4.3. So presumably msg_id + event_name should be "unique"?

Interesting that the mod_kazoo processes in your logs restart the event streams. I suspect your packet framing sizes are mismatched between ecallmgr and mod_kazoo. Check those settings (there's a recent thread about it) and hopefully that addresses the issue.

Thanks for the examples! I'll see if I can find time to try them out locally and reproduce the error you're seeing

By "funny money" I mean when you want to issue a service credit to your customer, say give them $20 for whatever reason, there's no credit card to charge or otherwise. It's just you updating their ledger with some "money". "real money" is when a CC is processed and those funds are added to the account to pay for services.