Jump to content

tomas_

Members
  • Posts

    785
  • Joined

  • Last visited

  • Days Won

    20

Posts posted by tomas_

  1. On 3/16/2018 at 9:53 PM, mc_ said:

    So when a call goes to the "Resources" callflow action, stepswitch (the app) figures out what carrier(s) to send the call to, right? But first it checks that the dialed number is not already existent on the system; if the number is found and it isn't forced offnet, stepswitch will hairpin the call back into the system for processing. So any numbers known to the Kazoo system will stay local unless forced to go out.

    So you could define an "internal" prefix of "+abc" and when you create your callflows, you create an "internal-to-kazoo" DID for that callflow as well. Now your Pivot app returns {"module":"resources", "data":{"to_did":"+abc1001"}}. Since you setup Account B's callflow to include "numbers" :["1001", "+abc1001"], and "+abc1001" is in the number database, stepswitch will hairpin the call to Account B.

    This is a hack! But if you accept the headache of managing this, it could be a way to accomplish your goal.

    caveat emptor

    Bumped into this now. How to restrict numbers not to force calls offnet?
    In our self hosted installation all calls to our DID's seems to be connected to the carrier, and not routed internally.
    Is it some setting in each number, or somewhere else?

    Br Tomas

  2. Nice!
    Great work! Thank you!

    However it doesn't work properly on my setup.
    There is no icon and no screenshot when initiating, see screenshot (the png's are actually there on the filesystem)

    Also the switchboard is "dead", it doesn't show any activity when making calls and nothing in the status log etc.


    I'm using HTTPS on port 8443 and Kazoo 4.3, if it makes any difference?
     

    Br - Tomas

    bild.png

  3. I'm not familiar with your specific issue, and not the setting that _mc mentioned above that sounds promising.

    However we've created some Pivot scripts to set the diversion header dynamically for each call, that approach might help you.
    Instead of "account/global carrier" in the "no_match" callflow we use Pivot to launch the script.

    An example of the output from the script with diversion header could look like this:
     

    {"module":"resources",
    	"data":{
    		"to_did":"NUMBER_TO_CALL",
    		"use_local_resources": true,
    		"custom_sip_headers":{
    			"Diversion": "<sip:DIVERSION_NUMBER@SIP_SERVER.COM>;reason=unconditional"
    		}
    	}
    }

     

  4. 48 minutes ago, Rus Yates-Aylott said:

    The message can by by-passed using the 'Use Mobile Voicemail' Option.

    This tells Kazoo that the keypress is not required so that voicemail or other IVR system can collect the call.

    image.png.08a392ec4396823d6e1a8bda051de154.png

     

    This is not a solution. I guess that @Harisur Rahman still want to use the "human verification" function.
    We've thought about the same thing, but I think a better approach is to use an app in the mobile device to detect a manual answer and send verification via HTTP Kazoo. However such apps isn't supported on iOS devices...

  5. Unfortunately I can't attend the conference :(
    But I totally agree with @fmateo05, Kazoo is awesome!
    It's not very common to develop in a system that (almost) always gives the feeling "nothing is impossible" - Seems like you've thought of everything, or made it work so good that it's possible to do exactly what you want!
    With other systems (like FusionPBX) we always needed to build a lot of workarounds and special solutions, that sometimes the WebUI would break afterwards...
    The API system is really great, that makes automations and integrations so easy!
    Thanks, and keep up the good work!!

  6. We have a 7 server setup in three different locations, all servers in the same zone.
    Datacenter 1: CouchDB 1, Freeswitch 1, Kazoo/Kamailio 1
    Datacenter 2: CouchDB 2, Freeswitch 2, Kazoo/Kamailio 2
    Datacenter 3; CouchDB 3.

    If one of the datacenters goes down, everything works as normal.

    The idea with CouchDB is that it handles replication automatically, no need to do manual replications if setup correctly.
    As of most database clusters, you need to have at least three servers on different locations to handle "split brain" issues.

    The idea is taken from https://www.powerpbx.org/content/kazoo-v3-single-or-multiple-server-voip-telephony-platform-install-guide-v1 (the guide is for Kazoo 3, but the basic idea works with Kazoo 4)

    However, nowadays it seems like all different services can run on the same server (CouchDB, Freeswitch and Kazoo/Kamailio etc), but we haven't tried it. I believe it's better for future expansion needs to have things separated.

  7. It is possible to change the recording, at least if you host your own system.
    Just upload a new sound file to the file system (preferably /opt/kazoo/sounds/en/us) and use the command sup kazoo_media_maintenance import_prompt /opt/kazoo/sounds/en/us/ivr-group_confirm.wav en-us. Note the filename ivr-group_confirm.wav, which is is important!)

    About notification on incoming calls we have developed a mobile app (iOS & Android) which sends push notices to the mobile that Kazoo is calling. This notification is received on the mobile before the call comes in, and contains info about the caller and which number he called etc. It's also possible to set up this push so Kazoo sends it directly when the call is coming in to Kazoo, before it connects to the mobile.
    The app also contains a lot of Kazoo functions, like user settings, CDRs etc.
    Contact me via PM if this sounds interesting ;)

    Br - Tomas

  8. The features we're focusing on is a pop-up function for incoming calls, and also CDRs and maybe call recordings. Click-to-call would also be nice but that's possible with browser plugins so we're not looking into that now.
    Please let me know if there is anything we can do to help, especially in PHP, HTML(5) & Java- / Typescript!

    Br - Tomas

×
×
  • Create New...