Jump to content

mc_

2600Hz Employees
  • Posts

    1,768
  • Joined

  • Days Won

    4

Posts posted by mc_

  1. Hmm, not sure where the problem is.

    $ curl -v -X PUT -H "X-Auth-Token: $AUTH_TOKEN" http://192.168.1.100:8000/v2/accounts/$ACCOUNT_ID/callflows -d '{"data":{"flow":{"data":{"method":"GET","req_timeout":"5","req_format":"kazoo","voice_url":"https://{SERVER}/pivot/script.php","debug":false},"module":"pivot","children":{}},"numbers":[],"patterns":["^\\*25"],"contact_list":{"exclude":true}}}'
    *   Trying 192.168.1.100...
    * TCP_NODELAY set
    * Connected to 192.168.1.100 (192.168.1.100) port 8000 (#0)
    > PUT /v2/accounts/36f9fc70e306b8900714bf284b863b94/callflows HTTP/1.1
    > Host: 192.168.1.100:8000
    > User-Agent: curl/7.58.0
    > Accept: */*
    > X-Auth-Token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImQ3OTNmNDA4NjdkMzFlM2JkNDFlZTU3NWYwYTk1MjAyIn0.eyJpc3MiOiJrYXpvbyIsImlkZW50aXR5X3NpZyI6IkZFTnkyQkd3dnNlQ1lxaUVwQXU0a3ZRdFNHREtnTVZIMmgtSjdqcHBORW8iLCJhY2NvdW50X2lkIjoiMzZmOWZjNzBlMzA2Yjg5MDA3MTRiZjI4NGI4NjNiOTQiLCJvd25lcl9pZCI6IjM1MzM4NmM5ZDdkNDg1ZTFkZjhmODRjZDk5NDI5ZWU1IiwibWV0aG9kIjoiY2JfdXNlcl9hdXRoIiwiZXhwIjoxNTI1OTgwNjQ4fQ.cIQMRemZCfwudU3Pm_h87wrAcLIs1tKiSpZ4nQ0a4_P3zJVAjkPD44Qep593uR3EJJCu4miI8tGqB1v6KD6LF_hYlAeb9aGIJDn_NQuwKz1_7VMrJVvPOOHZhlJF0rxNpnOXTsRlW6m51pZ7-o67DUu3KUIyUJ4TWkEnu-Unj-HADEb4BXe9La9A-QhIdakw6lCIpAITxMFFQDU-Elc9-9jIIVPTbGj5oae3U3T-AHYqRnlbczppodowT-V_FiyicDpKai-e2UPEWBV1eQkf0vI0dyAY9JGMtFbkk64ocuGOw96HjSyvhJDUMzNgdXPkEN6JA-6vPjVlH1ZG_eCM-g
    > Content-Length: 242
    > Content-Type: application/x-www-form-urlencoded
    > 
    * upload completely sent off: 242 out of 242 bytes
    < HTTP/1.1 201 Created
    < content-language: en
    < content-length: 1250
    < content-type: application/json
    < date: Thu, 10 May 2018 18:31:56 GMT
    < location: 2926f7a520b36cf337570146586aa06e
    < server: Cowboy
    < vary: accept-language, accept
    < x-request-id: e12c81ce816e04c6d317548f33004605
    < 
    {"data":{"flow":{"data":{"method":"GET","req_timeout":"5","req_format":"kazoo","voice_url":"https://{SERVER}/pivot/script.php","debug":false,"req_body_format":"form"},"module":"pivot","children":{}},"numbers":[],"patterns":["^\\*25"],"contact_list":{"exclude":true},"id":"2926f7a520b36cf337570146586aa06e"},"revision":"1-986a627d1c305599b4f41e443002ee15","timestamp":"2018-05-10T18:31:56","version":"{VERSION}","node":"sA6dSvoWhUzdXcDMEReg2w","request_id":"e12c81ce816e04c6d317548f33004605","status":"success","auth_token":"{AUTH_TOKEN}"}

    I would debug your PHP code as your JSON works fine for me using cURL.

    If you are getting a response back from the server, use the request_id to grep the server logs and see what it says (in debug mode).

  2. Hi @Andres Gomez!

    So a couple things:

    1. How is your callflow for *25 configured? Did you set that in "patterns" with a regex to match? Or "numbers":["*25"]? If "numbers", that will only match the explicit *25. If patterns, make sure the regex used will match what you're dialing.

    2. To return JSON from php, typically you set the header('content-type', 'application/json') and echo the JSON. Some basic PHP scripts exist that may help.

  3. The server config shows you how to prefer querying database nodes in the same kazoo zone and using the other zone as a failover (hopefully minimizing WAN latency). Since couch is multi-master, even if the data isn't on a given node, the handling node knows how to retrieve it from its peers.

    Each db server will have its own hostname; any on the same LAN (typically) should be in the primary list and any that live across a WAN would include the 'backup' signifier.

  4. Well, I would say don't use anything until you have a firm handle on installing/managing Kazoo itself. You don't want weird Docker networking or other unrelated issues clouding your mind while learning about Kazoo.

    Then you can check out orchestration tooling and containers and the like, so you at least know if an issue is Kazoo-related or otherwise.

  5. Well yes, Kazoo is flexible.

    If you have 0 customers, it doesn't make sense to get the beefiest hardware before you prove that you can sell your service.

    So start with what's easy for you to provision and get working. So maybe that's a couple VPS servers. Then you get enough traffic that your FreeSWITCH servers are having trouble keeping up. Now you can replace the VPS running FreeSWITCH with bare metal instances on the provider. Or you can build out a datacenter rack with your stuff, get better circuits, co-locate with your upstream carriers, whatever.

    So the architecture definitely grows with you as you grow the business.

  6. We ran the hosted platform on small Rackspace VMs for two years at the beginning. You can certainly start small and scale up as you go.

    If you plan on supporting smallish conferences only, then having lots of Pis or whatever to spread them out is fine. If you plan to support large conferences (for some value of large), beefier hardware will be needed.

    You need to define the load levels you wish to support and build the architecture to support those levels.

  7. Conferencing will be impacted most by the hardware you give FreeSWITCH. Run bare metal and with plenty of CPU/memory since conferences does a lot of audio muxing and transcoding. Everything else is pretty lightweight in comparison. Of course, you'll need to load test to be sure your setup is adequate. Testing max participants in a conference and max concurrent conferences to see where things go funky. Will you allow video conferencing?

  8. On 3/17/2018 at 10:58 AM, Josh Robbins said:

    it doesn't work - I get a system message saying "no channels" and then she hangs up on me. This must be disabled on the hosted platform. Booooooo

    If you are hearing a recording it is enabled but didn't find any matching channels.

  9. @FASTDEVICE this won't be possible since you won't be able to create the "internal" number properly. If you create it on the hosted platform, it gets tagged as a "local" number; as such, it would be forced outbound to the carrier, even though it exists on Account B's callflow. This prevents accounts from stealing numbers that don't belong to them and receiving calls for those numbers.

    Is there a reason why account B's callflow can't have a proper DID that account A can call? As mentioned previously, that DID will not go to the carrier if it has been properly purchased and configured.

  10. 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

×
×
  • Create New...