mc_

As stated, you can investigate Erlang's 'code' module for the add_patha/1 function or you can restart the VM and the path should be included automatically.

When the Erlang VM starts up, it catalogues what code is present. It sounds like you added Konami to the file system after the VM was started, so the VM has no way of knowing about Konami. You can add the file path to Konami in the VM or you can restart the VM and Konami should be included in the file paths searched by the VM when a module is used.

I'm not sure if its configured there or not. You could try it out and see or email support to ask?

There is support for using open office to convert to PDF: https://docs.2600hz.com/dev/core/kazoo_convert/doc/fax_converter/#openoffice-compatible-to-pdf

I'll be honest, no idea what you're talking about? When did Excel come into play here? Do you mean the CSV ratedeck you uploaded to Crossbar?

This is controlled by the limits doc of the account: https://docs.2600hz.com/dev/applications/crossbar/doc/limits/

In core/kazoo_speech, there are a couple ASR engines listed - Google, IBM, and iSpeech. I don't know how operational those are at the moment but worth looking into.

Check in your `system_config/hotornot` doc, the `filter_list` key (or run `sup kapps_config get hotornot filter_list`) and see if there is an entry in that list for "caller_id_numbers". If not, you'll need to add it to the list of filter options

If you want to have an existing PBX route through KAZOO, create it either using the "connectivity" API or as a "device". "Connectivity" configs use a backend service call trunkstore, most suitable for pure SIP trunking. If you want callflow features available before routing to/from your PBX, creating it as a "device" makes sense. The "ips" API is probably not what you want, in this case.

Indeed, you have the "request_id" value now! Grep your logs to see what the server did and perhaps it will suggest what went wrong. Also, as an aside, it is generally advisable to strip things like the "auth_token" value. All to easy to accidentally leak access to a cluster that way.

The response should have "request_id", the value of which you can use to check your server's logs (/var/log/kazoo/kazoo.log typically).

All indications are that marketplace means open sourced 5.x from discussions I've had. On the technical side, we've demo'd working marketplace integration with clusters. The CPaaS team presented at Kazoocon and the roadmap sounds like a rollout of select partners listing their existing apps on the marketplace and select partners participating in purchasing/delivering apps via marketplace to their clusters is next. Q2 2024 was listed as possible general availability of marketplace to the broader community which should trigger opening access back up to KAZOO repos related to open source KAZOO apps. Its obviously been a whirlwind as much of the company found out about the acquisition at Kazoocon and we're just returning home to process, get onboarded into Ooma, etc. But I am encouraged by discussions that open source does remain on the roadmap and, with the bigger resources of Ooma coming to bear on all aspects of KAZOO and 2600Hz's goals, I'm personally excited to continue building KAZOO and the open-source community around it.

I believe per-minute calls get a default deduction (regardless of rate) at the start of the call; if the call is rated and costs less, the account is credited back the difference. You should see logs from jonny5 (j5_* typically) talking about it (make sure you're at debug level)

1> UTC = calendar:datetime_to_gregorian_seconds({{2023,8,31}, {2,43,00}}). 63860668980 2> Mel = kz_time:adjust_utc_timestamp(UTC, <<"Australia/Melbourne">>). 63860704980 3> calendar:gregorian_seconds_to_datetime(Mel). {{2023,8,31},{12,43,0}} It appears KAZOO at least knows what time it is in Melbourne. KAZOO typically gives the API response in UTC seconds so I would investigate the UI conversion.

You still swap the account token for an auth token: https://docs.2600hz.com/dev/applications/crossbar/doc/api_authentication/

People still have Panasonic equipment in the field to support.

CentOS7-Rocky8 in-place upgrade, followed by a Rocky8-9 upgrade immediately after, is what we're targeting.

Nice, didn't know about that. Thanks for the pointer

Not sure the UI app is open-source but the APIs they use are: https://docs.2600hz.com/dev/applications/crossbar/doc/resources/

For clarity: we leveraged mod_erlang_event at the start of the project. We wrote, from scratch, mod_kazoo to better handle our use cases. The main one was mod_erlang_event expected only one Erlang node to connect to the FreeSWITCH node; it was a happy bug in handling connections that allowed us to have multiple ecallmgrs connect to mod_erlang_event. But there are many performance and features in mod_kazoo that KAZOO utilizes that mod_erlang_event didn't provide. mod_erlang_event is also written (and probably not maintained anymore) by Andrew Thompson (aka Vagabond). I'm not surprised the code isn't working. In short, mod_erlang_event is not compatible with KAZOO installations - any use or issues with it can be taken up with Signalwire but not sure they're keen on maintaining it either.

Check the INVITE and 200 packets' SDP payloads, verify the correct IP is present for FreeSWITCH's packet at least.

Check the SDP on the legs. FreeSWITCH should use your ext-sip-ip and ext-rtp-ip if bridging direct to the device over the WAN in the SDP.

Yes, running KAZOO in NAT'd environments requires this. I wonder how many clusters run like this?

@airsaywelcome! Thanks for the kind words. Look forward to your questions.

Agreed on having skin in the game, especially because we know they're using KAZOO as a core component of their main line of business. They're content to make a go of it alone though.