Jump to content

Karl Stallknecht

Customers
  • Posts

    1,154
  • Joined

  • Days Won

    21

Posts posted by Karl Stallknecht

  1. I couldn't agree more! :-) Our clients seem to all want something wildly different, so just being able to set it custom on each account without going through a ton of API calls would be huge.

    One of the things we love about the 2600hz platform is that we can customize all sorts of things on a per-account basis (i.e. extension length, feature codes, hold music, etc). Having the flexibility to be able to customize this too (easily through the GUI) would be awesome.
  2. The first example I understood, which is why we always wait to set e911 addresses until after the port completes.

    The second example I didn't realize was the case. I assumed that the PSAP would get the caller ID number from you, and then run a search to see which address was associated with that and then the address info from Verizon would pop up.
  3. Sorry, I think we're still on different pages...

    What I am referring to is ONLY while we wait for the number to port. We do not set an address on the DID during this period. All we do is set the customer's main phone number as the 911 outbound caller ID number at the account level (or device level).

    Once the number ports, we usually wait 2-3 hours and then go set the e911 address on the DID.
  4. Right, that was how I understood it...so using that logic, I always thought that if we set the company/device's e911 number to their existing number (which hasn't ported) then it will continue to use whatever was set by the company before us, so it will be fine assuming what was set by the company prior to us is correct.
  5. Hmm okay so maybe my logic has been off....I always assumed that if we setup a new client (prior to the port) that if we set the e911 caller ID to their existing number (the one that hadn't yet ported) it would be fine because the 911 info would be coming from their current carrier, not us, if they called 911. Is this incorrect?
  6. Ah no, please don't start charging for call recording :-( While the current system is a bit tricky trying to find and retrieve calls, it's super straightforward and we love the fact that we can use any FTP server. It would be nice if a simple interface could be written to access those calls easily (i.e. a link next to the call in the log). But I guess the advantage to AWS is that you can more easily write code to do this. I just hate paying for storage since we have tons of it available to us for free already.
  7. FYI 15 phones ringing is not 15 concurrent calls. It's not even 1 concurrent call. An incoming call is just sending tiny packets to the phone to tell it to play a ringing sound. When the customer picks up, then the actual call begins and uses up a larger portion of bandwidth.
  8. We have a customer with about 25 phones all in a ring group, and they've never reported any issues. Our other customers (even with the same number or more devices) don't have all of them in a single ring group, so I only have one example to go off of.

    What we often see when a customer complains about some phones not ringing in the ring group are a firewall acting up. Look in the call logs and see if some of the legs say "Recovery on timer expire" - this is *usually* a problem with the customer's firewall. Sometimes it needs a reboot, other times it is too restrictive and needs to be replaced with something else.
  9. I think people are asking for three completely different things here:



    1. A way to include custom config options on top of advanced provisioner which will override it. 

    This is something that only exists for Polycoms as far as I am aware (and is probably one of my FAVORITE features in advanced provisioner by far...thank you SO much Darren for having this included). Basically you just list a URL for a custom config file so we have a directory setup on our website with various client configs as well as standard configs and then just point to the URL.



    2. A way to force re-save all devices to re-generate config files after making a chance at the provider-level.

    I'm 99% sure this already exists...if I go into provider settings and change the DNS (like you used as an example) to 8.8.8.8, when I click save it asks me to confirm that I'm okay with re-generating all config files.



    3. A way to mass apply the same provisioning settings to all accounts beyond what is available in provider settings or account settings.

    As far as I know this doesn't exist, but it would be awesome if it did. Having to go and do the same thing on every device in a new account can be tedious and isn't easy to do quickly. Examples include putting two parking spots on BLF keys, or listing the generic custom config file URL. I realize it gets tricky when you use different phone models, but in my mind you'd create let's say a "Polycom Standard" template (for a specific Polycom model) which you could do things on like setup parking spots, and then when creating devices you would tell it to use the "Polycom Standard" template so that advanced provisioner pre-populated certain fields.



    I realize the support situation gets more complicated, but honestly how is this any different than someone uploading a custom config file to their phone directly via the phone's web UI, or changing settings via the phone's web UI? Isn't it the same thing? If you start changing settings past the default, then charge customers for it if they need support since they are modifying the standard use case beyond what your software is built to handle. That's just my two cents.

  10. We would like the ability to do this because we often times do new system setups and need to have their caller ID showing their actual business number before we submit the porting paper work. We like to fully install prior to submitting the port request, and because you manually do it there is often a delay before the DID is entered into the system on your end. Even with the new port manager though, it doesn't appear to let you use the DIDs in any capacity (including setting caller ID) if they are in port-in state.

    We tried simply changing the provisioning URL on some phones and it did some funky things. We decided to factory reset the phones first before changing the provisioning URL, so while that sounds cool, we probably wouldn't want it.
  11. One feature that Kazoo has that Monster doesn't is letting you free-form the caller ID at the account level. In Kazoo you can manually enter it, but in Monster you have to select from a drop down (in advanced call flows). Will this functionality be added? I know you can use Monster to manually enter it on each device, but I am wanting to do this at the account level.

    Also, will the Kazoo shutdown affect existing devices that have not been provisioned with the new provisioner yet? I know we won't be able to provision new devices or change config on existing devices, but what about just using existing ones? Will they stop working? I doubt we can go through and finishing converting all devices by March which is why I am concerned.
×
×
  • Create New...