Jump to content

mc_

2600Hz Employees
  • Posts

    1,768
  • Joined

  • Days Won

    4

Posts posted by mc_

  1. To add more, will your devices be doing HD audio? Video? Lots of transcoding between WebRTC (using OPUS) and PSTN (using PCMU)? Conferencing? If so, how many participants? Support for SIP over TCP/TLS/VPN/etc (basically non-UDP)? SRTP? Fax? Expected CPS and concurrent calls? Lots of presence/BLF/other features?

    As mentioned, you can create more zones to isolate load based on geography (typically). You can throw bigger hardware at the problem. You can buy bigger and bigger pipes. You can host and get cross-connects in the same data-centers with your upstream providers. But there's no magic formula for inputting X devices and getting Y infrastructure costs. There are best practices that get you pretty far but eventually something will crack and you'll need good monitoring to detect those cracks.

    So, yes, Kazoo can be (and is) deployed to support 250K+ devices. As you grow, different parts of the infrastructure will fall down and need improvement, and where those spots are tend to be unique values for each installation (esp since usage patterns tend to vary greatly).

    We can be your partner in that journey to 250K and anticipate a lot of the growing pains :)

  2. @Josh Robbins sorry! PR is a pull request - when a developer wants to change something in Kazoo, they issue a PR to be reviewed by the team then merged into the project. I'll issue a PR to change the schema, get a team member to review, and then the next upgrade of the platform will change the schema's restriction. So it will be delayed a bit from being realized on the hosted platform but will make its way there eventually.

    Does that clarify things?

  3. @Josh Robbins Ah, we can relax the schema to be 128 chars instead. I'll get a PR up today for that. If you're running your own system, you can edit the 'system_schemas / menus' document. Look under the "media" object for maxLength and change it to 128 (although, since technically you can put URLs there but of course RFC 2616 and 7230 say there's no defined limit - it is server-dependent - so...pick a value. It seems like 2048 is probably "big enough").

  4. Is there a  reason not to use the "user" callflow and assign/unassign devices from there as appropriate? Then you can have children of the user callflow action that branch based on the SIP response.

    {"module":"user"
     ,"data":{"id":"{USER_ID}"
     ,"children":{
        "sip:404":{
           "module":"resources"
           ,"data":{"to_did":"{FORWARD_NUMBER}"}
           ,"children":{"_":{"module":"voicemail",...}}
        }
        ,"sip:486":{...}
        ,"_":{
          "module":"voicemail"
          ,"data":{"id":"{VMBOX_ID}"
        }
     }
    }

    I think this would be more robust that managing a ring group (unless you have many users involved?).

  5. Regarding the API, it's all a matter of preference I guess. Joris posted about Postman that the UI team uses to whip up API calls quickly. I have scripts the authenticate and export relevant vars to my shell's env to speed up stuff. I know how painful it can be to track down what areas of Kazoo need intervention when DB changes occur.

    Anyway, if you can get logs of the first and second attempts (where first succeeds and second doesn't), it may be instructive on what the differences are. Nothing comes to mind for why that observed behavior is happening.

  6. This looks really nice!

    I would consider adding, either on the main README or in an INSTALL or similar file, copy/paste-able shell commands for each of the installation steps. What is intuitive and obvious to you may not be to others and having an example shell session will provide more feedback as people try setting this up for themselves. For instance, if I wanted to play with this, I would need to dig up how to add the user for SSH and sudo, running the Kazoo commands, etc.

    If there are more hooks into Kazoo that would make life easier for setting this up, do let us know! Anything we can do to facilitate easier setup and maintenance, we'd like to know about.

    Thanks again for this work and sharing it with the community.

     

×
×
  • Create New...