Karl Stallknecht

As far as I know, they're 100% totally gone after they are sent. We've had this issue a few times where clients' email providers blocked 2600hz servers and the voicemails were unfortunately lost forever. Our clients were incredibly irritated and upset of course. If this has changed, please feel free to correct me though.

Excellent question!!!

Unfortunately I've given up on these :-/ All of them (including the Panasonic TGP) had issues that our clients complained about. One big issue is none of them support BLF as far as I can tell so it doesn't allow clients to easily use parking spots. Almost all of our clients heavily rely on parking spots and having them manually use parking spots is out of the question.

I wonder if someone mistook me for the 2600hz Karl on accident haha

Wow, I'm honored lol

I guess that would work, I just didn't think about it from that side. I was thinking about something moreso built in.

Okay, so how about just an email notification if a device doesn't answer a call? (NO_ANSWER or something I think...) I guess this would get messy with ring groups though...the "ignore completed elsewhere" option doesn't seem to consistently work with all phones.

Not just slack...missed call notifications would be great emailed too! Maybe like a daily report or something, or on a per-call basis.

That's what we do, but I think Darren got upset because it generates a lot of bounces on their end.

Hmm, someone from 2600hz will have to add you to that section of the community. Sorry!

See: https://helpcenter.2600hz.com/2600hz/topics/best-practice-out-of-office

The feature is there, but they later discovered that they needed to do a few things to enable it on production. Ticket KAZOO-4062 was to track them doing those things. It won't be available in the GUI the last I heard, and is just something that you can do either with an API or they can do manually from their end. But as of right this second it is not available.

See ticket KAZOO-4062 in JIRA. Unfortunately that is all I know.

Not sure about having a device on-site, but I do know that they finished building integration so that you can stream a SHOUTcast stream. It should be released pretty soon.

Right, but this *could* be a situation where they intended it to work that way or if they make it work the way you want it could break something. I'm just commenting from the outside though, I do not know for sure. I agree it's frustrating.

I'm not sure if 2600hz considers this a bug, but I would inquire with support if I were you.

We noticed this a while ago so we just removed the stop recording function...I know it's redundant but we just let the voicemail recording be recorded in the call recording. Turns out our customers actually prefer this because then they can tell via the call recordings who leaves a VM vs who hangs up before without having to compare it to voicemails. But yes, it's a waste of storage and redundant :-)

No worries. For us, both inbound and outbound calls have the call ID in the filename so I would assume that's the situation in your case as well. FYI I would recommend setting your FTP server to use the same time zone as the account. This way it's easier to find calls since you can sort by date and time.

This filename is the call ID. You can find the call ID by going into call logs/history and clicking the details or gear icon.

Whoa, wait a second guys! First of all, be careful about that documentation. It's a bit dated and 2600hz has said they are not updating it. I've found a lot of errors from things that are just outdated or no longer true. Secondly, while what you mentioned in terms of left to right will work, it's easy to mess up AND it can be a huge pain since you can't change the order and have to re-create the callflow to change the order. What I *highly* recommend is as follows: 1. Create a call flow with your DID(s) only and point it to a second callflow with an extension (i.e. 500) 2. The callflow with extension 500 can be your regular TOD "router" as we call it. This can have the different days of the week and corresponding times. 3. Now let's say there is a holiday or unexpected staff meeting...simply go to the call flow with the DID(s) and create another TOD. For example, set it to a specific day of the month and time and then set all other times to transfer to callflow 500. 4. This way if you forget to revert it you have 364 days until it becomes a problem again, rather than it potentially "closing" you the next day or next week. Also, it doesn't involve re-creating any callflows and also makes more sense and is less prone to error since a completely different TOD function is handling the abnormal circumstance. Just my two cents though! :-)

For the record, I agree with you on all points :-)

We asked 2600hz to increase the limit previously and they said they did not plan to increase it. They told us to just lower the resolution on the PDFs. As for the difference in quota calculation, the following is from 2600hz support from a previous inquiry we made about this. Maybe it's related? ------------------------------------------------------ Strange find. Email clients (on your side) have two ways to say "hi" to our mail server, HELO (older version) and EHLO (enhanced HELO). Most of our testing was with clients who do EHLO. Your client did the older HELO. There was a difference in file size between the two. We've now made the two match so the file size limit is the same. Please retry. From engineering: "fax_smtp was running with different defaults for HELO and EHLO. HELO was restricted to 640kb. Microsoft exchange/smtp usually uses HELO instead of the more common EHLO." ------------------------------------------------------

https://2600hz.atlassian.net/browse/UI-2234 :-)

Very good idea! 

Thanks, that makes a lot more sense. When will it timeout (i.e. would it end up going to the cell phone's voicemail or does it only ring for 15-20 seconds or something)?