Darren Schreiber

Hi Rick,     While I get your points, the key exchange thing doesn't even solve half of what I listed, while adding another training/complexity point just in teaching the user (Forget the code part). Ugh. Yeah, MESS.      This is very much NON-TRIVIAL.       I think we will probably end up supporting this scenario: "First is for a single company with multi-locations. For them, really it'd be mostly about using Smart PBX. Man oh man it's hard to convert someone from using Smart PBX to ADV callflows just because they add a location. They hate it."  I agree with that use case. The value of SmartPBX is being able to stay within it, and the use case is common. This one: "Second though is separate companies that want to be affiliated for some reason. For instance, I had three clients that shared adjoining suites. They relied on each other heavily and wanted to be able to page/intercom/ect so I put them into one account. Well, then they eventually split up and went their separate ways. " Honestly, this one is where, as a reseller, you gain a backbone and you say to them, either re-setup your account, or we bill you for having to manually do this. Do not sell them anything that entitles them to break up later, that's absurd. I know of no company who puts up with this scenario as somehow included or expected to be a feature of the system. And this instance is so rare. This one: "I've also had a virtual receptionist company approach me wanting a way to see status of their clients.It was really hard to see a multi-hundred handset account walk because I had no solution for that." I agree this would be nice, but then it'd require tackling all the technical complexities I listed. I agree we should do it someday, but the multi-office company is far more of a common occurrence then this particular type of client, and this is just one of their requests. Once you can say you do this, they want 82 other things (like custom reports on a per-customer-we-service basis, etc.) so this is just the tip of the iceberg if you want to support receptionist companies who handle multiple clients. I'd argue that you should do more homework here on ALL of the things they are going to require (not just this) because there's a LOT of them, and you're only mentioning one.

Yes, same as the graphics posted above. You have a callflow for enable and a callflow for disable. They consist of: Callflow 1: Manual Presence On -> Enable Time-Of-Day Callflow 2: Manual Presence Off -> Disable Time-Of-Day You program those into two keys on the phone. On a third key, you monitor the presence of the light. It might be possible to do it all on one button/light but I don't think so.

It's not ridiculous. It is expensive :-) We're debating what to do about that. If we end up fielding support calls every time someone sets up a client with Google Cloud Print this will be one of the most expensive services we've ever rolled out, with no ability to "fix"/change the behavior.

So I spoke with engineering and it's not tied to the time-of-day unfortunately. However, they stated that when it was built the idea was: 1) Create a callflow for "activating Time-of-Day" with a Manual Presence element that turns on a light and then goes to the Enable Time-of-Day. You can set the presence name to anything you want (say, "tod_night") 2) Create a callflow for "disabling Time-of-Day" with a Manual Presence element that turns off the light and then goes to the Disable Time-of-Day. You can set the presence name to the same thing as #1 3) Set the phone to subscribe a light to the time-of-day name The only catch with the above is you can't make it so pushing the button dials the correct enable/disable sequence I don't think. This would result in the desired behavior most likely.

I just wanted to reply to this, even though I know the thread is a bit old. Karl asked: "Now the only other thing that would be helpful and help mimic an analog system would be a way to setup a BLF key so that it could light up to show that the system was in "night mode" like a standard PBX will let you do so that the receptionist will see it when he/she comes in every morning as a reminder to take the system off of night mode." I believe there is a way to do this. I'm checking on it, but we did code this at one point.

This is such a HUGE can of worms, I don't even know where to begin. Allowing people to cross-subscribe BLFs and transfer to each other, how do we now make sure the account really applies to you, the reseller? This would mean adding additional code and database load to make sure on every single action the system does we don't just authenticate the account but we check to make sure everyone is under the same reseller. Huge challenge. Plus, let's say account A wants to call an extension in Account B. So Account A dials a number. We check all numbers in Account A, no match, so then we check Account B, no match, then we bounce back to Account A to process the no_match rules? What if both accounts have pre-flows set? Which one do we run? Both? What if they conflict? And worst of all, how do we teach all the administrators all of the above edge cases (and the countless other ones that exist)? How do you manage credit across two independent accounts for a company that wants to be treated as one? I could go on. I think a bigger solution is simply to allow multiple receptionists on the same account. Which you can already do via advanced callflows anyway. Then perhaps we add a field called "location" to each device or user and record that with CDRs, so you can report on how much each customer spent based on location, in case a location wants to be billed independently. But splitting the accounts and then allowing features between them is a huge nightmare - security, complexity, training, the whole nine yards.

Hi there,      I've had this issue, too. I don't know why they do this. It's definitely not something we have control over. They seem to be doing a lookup and maybe comparing documents on the web with any occurrence of the phone number?

Hi Anthony,      We demonstrated the Google Cloud Print integration at KazooCon. However, when we deployed it to a test group, NOBODY could understand how it works. Like, literally, everyone couldn't figure it out. Google requires you to register a printer with these auth IDs which must be done from your own Google Account, and must be set for each individual account with a Unique ID that you have to track and copy/paste into Kazoo. Apparently this was just a huge issue.       So we shifted instead to email to fax for our focus, because everyone seems to know how to use email.       We may pick this up again, we're not sure. You're the first person to ask about it in a long time.

There is not enough data in this report. There is no screenshot showing exactly where you are (though there is mention of the "Smart PBX Call Log" but perhaps a filter is on or something else? Can't verify without the screenshot). There are no reproduction steps. There aren't specific call examples.

2600hz does offer MPLS connectivity services, but they are expensive. These are direct, secured lines to from our datacenter to your customer. The lines can cost between $500-2,000 a month and are based generally on distance to the local CO from each end (our datacenter and your customer), a link between the two COs, and speed. It is fairly common for connectivity to be done this way.

We've just updated the code to hopefully put the "disappearing app" issue to bed. If this doesn't work, we're probably going to need to do a screenshare with willing participants to see why it's not working. Please re-test and let us know if this resolved it.

Hi Michael,       Katie has correctly answered this question. It's dependent on the manufacturer and the model of the phone. You would find this answer in each phone's documentation, and it varies per phone (though most phones it's you and two other parties max).      In scenarios where the phone itself is creating the conference, the audio mixing is actually done inside the phone itself, not in our service. Therefore, the limitation is based on the phone's capabilities.

Is the timezone coming from your router? DHCP has the ability to assign an NTP clock source, which would include a timezone I think? https://tools.ietf.org/html/rfc4833 Or maybe you are actually in Havana and you didn't know it? Or your computer is trying to tell you to take a vacation? Just a thought... ;-)

Joy,      When you say you "switched back" to prv.zswitch.net, that's kind of a red flag. Devices built in Monster will be provisioned via p3.zswitch.net . Devices built in Kazoo UI will be provisioned with the old prv.zswitch.net . Where did you actually build the device? The two URLs are not interchangeable.

There are two RTP streams - one going to you, and one going from you. If the person pushes mute to listen to someone talk, boom, you might have 15 or 30 seconds or inactivity, and the call is hungup. (Hence why this feature seems incredibly dumb) I'm sure there's some way to make our servers behave nicely with it, like periodic RTP packets, but again, seems dumb to us. VoIP specifically has a feature to reduce bandwidth consumption which allows NOT sending audio when there is none, and we utilize that. It's indicated in the headers that we're using it, and the phone accepts it, but then doesn't respect it. (This is also why other providers don't have this issue - they don't use this feature).

To be clear, the problem with the simultaneous call scenario is that the calls are still actually "attached"/up on the softphone, even when not being used by the user. Thus, the call that was on hold had "no audio". The RTP timeout would kick in when nobody was talking, and bye bye caller.

Definitely turn off the RTP inactivity timer. That's a nasty feature they started shipping and it's on by default. It should be off.

There are some "magic" numbers in VoIP that are very telling: 1) Calls that drop at 30 seconds. The way VoIP works, we send a packet to the phone saying "please start ringing" (an INVITE). The phone replies that it's ringing. It then sends us a packet back that says "the person you are ringing has answered!". We send back an OK indicating "OK, we now know that both parties are on the line - let them speak!".   If one of the last two messages has any sort of problem (typically the OK), there is a retry interval for 30 seconds (by default). If the retries continue to fail, the call will disconnect. This sounds like your issue. I'd check your softphone and make sure RPort and media timeout settings are correct. 2) Calls that drop at 10 or 15 minutes. This are magic times when a lot of carriers check to see if a call is really still up. If the SIP signaling port has become closed by a firewall/router, but media is still flowing, the signaling which checks if the call is still up will fail (even though the call IS actually up) and the call will drop. This is almost always a firewall/router issue. 3) In terms of firewalls and debugging, there's a magic rule on debugging audio vs. call connectivity as well: * If the call connects, but has no audio or one-way audio, your problem is almost definitely firewall related and is related to ports UDP 16384-32768 or the RTP ports specified in the GUI of your phone * If the call fails to connect at all, your problem is almost definitely signaling which is port 5060 or 7000 depending on your configuration. Based on your description, I think it's #1 above. Posting your softphones settings, especially the advanced / network tabs, would be a good starting point.

Nope. On the Account tab, you had to put in a server/domain name. Add :7000 to the end of it. OR if there's a proxy, enter :7000 at the end.

No. A delay in audio is almost always an over-aggressive firewall that is blocking the initial audio packets because it thinks they are an attack. When you say "Bria4 Softphones", is this on a mobile device or a laptop or what? Bria has two types of softphones - one for mobile phones and one for laptops / desktops. In both cases, my suspicion is: 1) You've manually provisioned the device and it's not using port 7000. Try adding :7000 to the proxy address you've configured, or if you didn't use a proxy, the realm/server your configured of the customer's. 2) You should make sure "RPort" is checked in the advanced / Transport section of the phone's configuration.

Maybe an alternative is to post a list of things you'd use from a native app that was smaller / simpler?

No plans for cell phones. In fact, we explicitly excluded them during our design because it really isn't practical to make a one-size-fits-all responsive design for such a complex GUI. We did, however, spend a LOT of time on supporting tablets. If you're taking this to client sites and want to show off, invest in a tablet :-)

Thanks for the positive feedback. There are a bunch more cool items coming to this tool. Watch for it.

Karl, can you be more specific as to where it's defaulting to Cuba? Screenshot might help. It's supposed to be coming from your browser, which usually sends your system's timezone selection.

It is still there. Try re-enabling it?