Jump to content


2600Hz Employees
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by mc_

  1. Hi Ash, First, welcome! Glad you're here! I would start by looking at the SDP in the A-leg's INVITE to see codecs offered, as well as what codecs are then offered to the B-leg from FreeSWITCH. Could be a transcoding issue or misconfigured codec selection. Payload type 0 is typically PCMU but you're log shows PCMA being used. Perhaps look into what codecs FreeSWITCH thinks are loaded? `fs_cli -x 'show codecs'` should list `codec,G.711 ulaw,CORE_PCM_MODULE` among others.
  2. You can disable call_waiting on the device or user config: https://docs.2600hz.com/dev/applications/crossbar/doc/users/#call_waiting
  3. @Shah are you creating one connector doc per PBX or one doc for all the PBXes?
  4. @Pargat sounds like, unfortunately, a lot of spam and malicious traffic originates from various countries; operations has blocked large swaths of IP blocks to combat it and you appear to have been caught up in that. We're working on getting a mirrored host up so that folks like you can access the repos without needing to resort to a proxy or VPN. More to come!
  5. Not aware of any restrictions (asking around). Can you try fetching that URL with wget or cURL and see what they say?
  6. You cannot, SUP is only for the cluster administrator. What are you trying to do as a sub-account that you need them to use SUP for?
  7. @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.
  8. 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
  9. 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.
  10. Everything about this log suggests it hung up. Check the FreeSWITCH logs to see if it generated the SIP BYE?
  11. Where are you trying to set defaults? In provisioner or via KAZOO API or?
  12. Map the softkey to a callflow with https://docs.2600hz.com/dev/applications/callflow/doc/group_pickup/
  13. 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.
  14. @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...
  15. 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!
  16. Not sure what OSes will be targeted. I think CentOS7 will continue and hopefully a Debian variant. Not sure on timeline for CentOS8 though...
  17. @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.
  18. 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!
  19. 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/
  20. 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.
  21. @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/
  22. 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?
  • Create New...