[escript: Failed to open file sup.escript]

Is the sup escript not at `core/sup/sup`?

[Process to change the core Kazoo function names]

`make xref` from the root directory will check that called modules exist and throw errors for mismatches. As for how to integrate that into Eclipse, I only know of Erlide that may help you with Erlang code.

However, I question the renaming - you're setting yourself up for a lot of work to maintain your changes for minimal value (speaking personally). But if you're good with that, you do you

[Usage of PIVOT for a dynamic callflow]

You are on the right track. You need to use the channels API: https://docs.2600hz.com/dev/applications/crossbar/doc/channels/#execute-an-application-against-a-channel

Enable metaflows on the account, execute your pivot request as before, then use the Channels API to interact with the call in progress. You'll need Konami running to handle the call manipulation.

[Inbound Call Barring]

Don't assign the account a DID and it won't receive a call for that DID. If you must keep the DID assigned to the account, create or edit the callflow for the DID(s) to use the "response" callflow action to respond to the caller with the SIP response code of choice.

[libwebphone issues]

I found updating the FreeSWITCH candidate ACL list to allow local IPs works because FreeSWITCH will auto-adjust the RTP stream based on what is being sent from the browser.

[Call Recording Retention]

AFAIK there are not; accounts (or their resellers) should maintain those by cleaning up as necessary.

As a feature request, this would be pretty straightforward to implement as a task for the tasks app, though.

[Call recording PUT request to https]

What version of KAZOO? What type of cert? Is the https address publically accessible for us to try? And what are the logs for the attempt (probably log lines prefixed with `kz_http`).

[Referencing System Media files]

Just checked the 4.2 code and indeed, the menu callflow action does not construct the URL in the same way that 4.3/master do. Sorry, I should have asked your version at the start. So this will definitely work when you upgrade to 4.3

[Referencing System Media files]

@simonp22 all tests work in my environment. What version of KAZOO are you running? I recommend updating to the latest 4.3 and trying again.

[In-Call Feature for Conference via DTMF]

There is an API for dialing out to participants and adding them to the conference: https://docs.2600hz.com/dev/applications/crossbar/doc/conference/#endpoints

So the functionality exists to create the dial-out but nothing is currently in place to listen for DTMF and execute the bridge accordingly. Good PR opportunity!

[Referencing System Media files]

@simonp22 no haven't had a chance to try it myself. Let me see how my day goes; I may have a couple minutes this afternoon to setup a test. Thanks for the reminder.

[change in license?]

Hi @enkp,

You can read a summary of changes from 1.1 to 2.0 here: https://www.mozilla.org/en-US/MPL/2.0/Revision-FAQ/

The main bullets for why to upgrade from 1.1 are:

• MPL 2.0 makes compliance simpler, both for you and for people who receive code from you.
• MPL 2.0 provides patent protections for you and your contributors more in line with those of other open source licenses, and allows your entire community to protect any contributor if the contributor is sued.
• Compatibility with Apache and GPL makes code reuse and redistribution easier for you and for the broader open source community.

So just as we keep our dependencies updated, this is making sure our license stays updated to make it easier for everyone.

[libwebphone features]

Hi @Paria

As far as I know, libwebphone is a basic phone for making and receiving calls. It can also initiate transfers.

That said, it is mostly a wrapper around JSSip: https://jssip.net/

So whatever you see capable in there could be exposed in libwebphone as well. Contributions definitely welcome!

[Access to Sandbox]

As far as I know, sandbox is generally reserved for paying customers; ask your rep about access. If you aren't a customer of 2600Hz, you can email sales@2600hz.com about getting access, explain your interest, and they can determine whether to set you up with access.

[Kazoo Webhooks modular git sources has another kazoo branch]

No, 5.0 hasn't been tagged yet. The master branch represents 5.0 at the moment but is not considered "stable"; 4.3 remains the suggested install version. Hopefully by the end of the summer we'll tag 5.0, do the breakening, and all that jazz.

[Kazoo Webhooks modular git sources has another kazoo branch]

Umm, kazoo-mk is not the new build method (it explicitly states a temporary repo to explore ideas for a new build system).

The breakening has not officially happened; much more fanfare and announcements will precede the actual event!

For now, master/5.x is being developed in the regular kazoo repo. More to come!

[Referencing System Media files]

I just checked and I'm pretty sure `/{ACCOUNT_ID}/{MEDIA_ID}` will work (at least in my tests of the underlying code paths). Add the preceding slash and you should be good to go.

[Voicemail Pin Length]

@Jack Noe ah, I see. Entering the PIN on the voicemail callflow restricts the length to 6 digits. But this is out of sync with the schema, hence the confusion.

The reasoning for the restricted length was to keep people from using their phone numbers as their pin but that restriction was encoded as a system_config value instead of updating the schema.

Talking internally about path forward here to fix the issue. File a support ticket if you'd like to lobby for a higher limit.

[Voicemail Pin Length]

The schema allows for 4-15 length pins:

curl https://api.zswitch.net:8443/v2/schemas/vmboxes | python -mjson.tool
...
            "pin": {
                "description": "The pin number for the voicemail box",
                "maxLength": 15,
                "minLength": 4,
                "support_level": "supported",
                "type": "string"
            },
...

Where are you seeing the error?

[Voicemail Pin Length]

Looking at https://docs.2600hz.com/dev/applications/crossbar/doc/voicemail/

Appears "pin" must be a string of length between 4 and 15.

What version of KAZOO are you trying this on?

[Referencing System Media files]

Can you pull debug kazoo logs of a call attempt? Would be helpful to see what was tried.

[Referencing System Media files]

The system_media prompts are intended for the pre-built callflow actions, such as the voicemail prompts, and aren't generally meant for account-level usage. Does that make sense?

Instead, you would upload a media file to the account (or a reseller/master account) and reference it with `{ACCOUNT_ID}/{MEDIA_ID}`.

You can also try `"greeting":"/system_media/{PROMPT_ID}"` in the JSON if you really want to use a system prompt in a menu callflow action. I think it might work but buyer beware!

[Line Name On Provisioned Devices]

@Rick Guyton the change occurred in KAZOO, in how the data was sent to the provisioner service.

 

The PRs have been issued and merged. Hotpatches to hosted will be scheduled when OPS can do it; not sure on the timing.

[Line Name On Provisioned Devices]

PR - pull request on the git repo. Once the PRs are opened and merged into the 4.3 and master (5.0) branches, new RPMs will be created containing the fix. We'll also likely hot-patch the platforms we manage to alleviate the issue.

Timing for the updates/hot-patches is unknown until the PRs are accepted and we see what the OPS workload is. But we'll update here when things are live on the various systems we manage.

[Line Name On Provisioned Devices]

Consensus is to revert back to the pre-existing functionality and let you guys continue to operate as you did before this change. Look for PRs for 4.3 and master in the next day or two.