Jump to content

Darren Schreiber

Administrators
  • Posts

    1,202
  • Joined

  • Last visited

  • Days Won

    27

Everything posted by Darren Schreiber

  1. It's reasonable to accept it should work. We have to make that the target.
  2. That's unfortunate. While there was an issue last Monday/Tuesday, it was resolved. I would not agree that this should stop you from mission critical clients in the future, but it sounds like the timing on this did kill it for this customer. Obviously nobody wants that to be the end result. Sorry to hear this lost you your deal. Hopefully the next one will work out better.
  3. The old posts are too hard to merge back into the restored community, so they are lost. You will need to re-post your content if you still have an open question/comment I'm afraid.
  4. Basically you have to program the phones first unfortunately. It's the only way (for now). We are working on a whitelist IP for 24 hours mechanism.
  5. Nope, not if they load known files perfectly.
  6. Yup, that's what you hit. Basically don't plug in the phones until they're configured, as a rule, and it should be fine. And don't try to load configs from a browser. I can unblock you manually if you msg me your IP.
  7. You don't mention what's in the callflows besides that they hop to one another. So there's not enough information in your posting to understand what you're doing. Can you post the callflows themselves (screenshots)?
  8. The compiled versions are. Good question what happened to the scripts which create them. @Karl Anderson any ideas?
  9. Yup, soooo we host this outside of 2600Hz datacenters and apparently the provider rebooted the box. I thought we restarted all services but postfix did not auto-start. The mail has been queueing though. So all the emails should have just been delivered that were queued. Sorry bout that.
  10. That is, basically by definition, a call queue, yes.
  11. I understand the description, but it doesn't sound like the right analysis. So I'm hoping for more concrete information - like a sample or logs.
  12. The timeout is based on your progress timeout, no? Are you sure that faxbox times out at 10 seconds? I really don't think that's right.
  13. @FASTDEVICE Is correct about the "complicated" part of this. The current method of enable, disable, reset allows us to: Set the time-of-day's state/status (open/closed/auto) on a document, and is triggered by someone dialing a code or hitting an API Check the time-of-day's state/status when it's dialed to see what it's state is This means both the above two actions ONLY happen (i.e. the document with the state/status is ONLY checked) when someone takes an action. This means if the system has 100,000 time-of-day config documents, they're still only accessed at the time they're actually being used. With a "temp disable", we now need to either: Introduce a "crawler" which crawls the database one account at a time, looks to see if any time-of-day's are in "temp" mode, calculates if they still should be or not, and resets them Figure out a way to track what the system did so that there's no "mystery black magic" such that when a support ticket comes in, we can see when/why the system may have reset a state/status (right now we can generally figure out what happened by looking at CDRs for dial codes, or API requests) Alternatively check the time-of-day state/status to see if it's "temp" at the moment a callflow is called, to see if it should no longer be in "temp" mode, but this means BLFs/etc. will be inaccurate until a call is actually received on a flow where the time-of-day should have been reset, which may confuse people So, there's not a great solution to this without a crawler/background scheduler. Which makes it a complex task. This actually seems like an easier task to do externally, frankly, via an API script or something customized. I would encourage folks (like FastDevice) to consider a module on their side that people can buy/sign up for since I think this is also not a super-common request (though not uncommon either) and would be better suited by a simple program running "along side" Kazoo as an add-on feature.
  14. I *think* in our system that if they're using a system phone and our conference bridge, we automatically disable the hold music for this very reason. Are you sure this issue exists?
  15. When you say "your sandbox" is that a separate server or your hosted 2600Hz one?
  16. To be clear the ISO was actually an auto-installer that would download the latest version from the web. That said, it was for 3.x. Hasn't been updated for 4.x. But the date is not so relevant. The configs changed from 3.x to 4.x though.
  17. Would need the logs but it sounds like it's advancing to the next carrier after a reject.
  18. What version is this on? This sounds like the reject is generating an error but a retry occurs on your next carrier selection.
  19. Nice job everyone with all the suggestions, this is an awesome thread. I hadn't even thought of a menu, Rick! Great idea! Karl, I don't understand your reply. Why can't you use the same Time-of-Day option in multiple callflows to determine if the office is open or not? Then you only need one BLF light, despite the time-of-day being used in multiple callflows.
  20. How does that accomplish telling the PSAP what room or floor the person is on?
  21. Also there's only like 3 actual certified VoIP PSAP interconnect companies, everyone is just reselling their stuff. I believe it's 911 Enable (now West?), Intrado (also now West?) and bandwidth.
  22. Hi there, As far as I know, every number gets a unique address (even room number) so I am not aware of a way you can transmit the specifics of the room or location number with granularity at this time. If someone is working on that, it is news to me - right now they make money off each of those numbers so there's no motivation, to my knowledge, to fix that. We played with an idea at one point to change the APIs in realtime - person dials 911, we update the API with the latest address, pause for 2 seconds, then connect the call, but decided it was a terrible idea to have someone wait on the line, even for 2 seconds, when calling 911, so abandoned that (without the pause the databases didn't seem to update reliably enough / rapidly enough). So I am unaware of a solution to this besides paying per number.
  23. Both these items would need to be features the phone itself supports. The first one I've never heard of a phone supporting, though it may exist, because you are actually opening two calls at the same time, and outputting audio on two different components on the phone at the same time. I don't know of any phones that will do that. The second one is also tricky - the phone has to acknowledge / send to the server when the handset is lifted, or automatically go on mute when on speaker and off mute when lifted. I don't know of any phones that will do that, either. As far as I know this has no relevance to any software running on the server side.
  24. OK, for those on-lookers. I've just gone through about 15 of Tuly's accounts and now believe that the information he is posting here is not accurate. For the sake of avoiding any misleading assumptions by other customers, we CAN NOT produce any failing packet traces except from ONE of Tuly's locations thus far. So, until I have something more conclusive that shows this is more widespread, please note that I do not think there is any issue on our equipment or with our network provider in EWR at this time. Happy to investigate more reports, and waiting for Tuly to provide a more comprehensive list of where he's seeing failures, but at this point, I can't reproduce this, including to his own customers, so I want to prevent any FUD on this thread until I have more data. I'll circle back when I've collected more data.
×
×
  • Create New...