Jump to content

mc_

2600Hz Employees
 View Profile  See their activity

  • Posts

    1,766

  • Joined

  • Days Won

    4

 Content Type 

Profiles

Forums

Resource Library: Monster UI Apps for KAZOO

Events

Downloads

Everything posted by mc_

  1. mc_
    I mean the RPMs aren't hosted by 2600Hz anymore, as far as I know anyway. Perhaps there's an archive somewhere. But more importantly, why can't you upgrade production? There are a myriad of reasons why you should be upgrading, chief among them security improvements. What limitations are you up against to upgrade off a 3+ year old version of KAZOO?
  2. mc_
    @Dhoine 3.20 is not supported. 3.x is not supported. 4.3 is supported. 5.0 will be released in the near future. What's preventing you from upgrading to 4.3?
  3. mc_
    Correct; once set they will appear on all subsequent call events for the leg (via webhook / websocket if you ingest those) as well as the CDR.
  4. mc_
    You will need to consult your logs to see that callflows sends the metaflow request to start the Konami listener and that Konami is receiving the DTMFs and attempting to match them to a metaflow.
  5. mc_
    Did you configure metaflows on the account? https://docs.2600hz.com/dev/applications/crossbar/doc/metaflows/#set-metaflows-on-the-account Unfortunately, you need at least one metaflow (even a basic no-op one would work) to trigger this functionality with Konami.
  6. mc_
    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.
  7. mc_
    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.
  8. mc_
    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.
  9. mc_
    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.
  10. mc_
    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`).
  11. mc_
    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
  12. mc_
    @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.
  13. mc_
    @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.
  14. mc_
    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.
  15. mc_
    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!
  16. mc_
    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.
  17. mc_
    @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.
  18. mc_
    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?
  19. mc_
    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?
  20. mc_
    Can you pull debug kazoo logs of a call attempt? Would be helpful to see what was tried.
  21. mc_
    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!
  22. mc_
    @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.
  23. mc_
    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.
  24. mc_
    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.
  25. mc_
    We're meeting about this today. Should have an idea of what next steps are then. Sorry for the disruption; hopefully things will be sorted out and a proper announcement can be sent around all this.
×
×
  • Create New...