Darren Schreiber

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)?

The compiled versions are. Good question what happened to the scripts which create them. @Karl Anderson any ideas?

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.

Yes, we plan to add a download button to download the configs manually.

That is, basically by definition, a call queue, yes.

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.

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.

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

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?

When you say "your sandbox" is that a separate server or your hosted 2600Hz one?

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.

Would need the logs but it sounds like it's advancing to the next carrier after a reject.

What version is this on? This sounds like the reject is generating an error but a retry occurs on your next carrier selection.

#3 is because of spaces. Search with no spaces or special characters in the search box. It's a bug, the UI or the back-end should strip the non-alpha characters (just like the login screen). I have already filed this bug.

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.

How does that accomplish telling the PSAP what room or floor the person is on?

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.

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.

Avoids hackers scanning for open ports that reply, and then sending them harassing traffic where the phone rings randomly with fake Caller IDs like "test" and "100". Basically it's a protection against crummy firewall/routers that are full cone NAT. See https://en.wikipedia.org/wiki/Network_address_translation for more.

I use 10000-65000 I suspect both handle and via rport but you can actually skip that option unless you have trouble with one-way audio.

Make sure to always: * Change the local SIP port to a random even number * Enable rport * MOST IMPORTANT: Ensure your outbound proxy is a DNS name with SRV and that SRV is enabled (such as us-east.p.zswitch.net)

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.

Thanks @azefiel It's important to note that what is being proposed in the tutorial above IS SAMPLES READY TO PLAY WITH! They are like a pre-loaded collection of examples (but real ones) that you can manipulate and use. They become a collection of every API. I wonder if we can find somewhere central to keep the postman collections.

:-) This is why we have a forum now. I forget things. (For those of you not aware of what Chris is doing, he just publicly shamed me in our company meeting for forgetting to nominate this feature. It has now been nominated).

I swear we added this. It's been discussed like 50 times internally. That said, I don't see it. grumble grumble. I'll bring it up at our next product roadmap meeting.