Jump to content
KAZOOcon: hackathon signup and details here! ×

Karl Stallknecht

Customers
  • Posts

    1,154
  • Joined

  • Days Won

    21

Posts posted by Karl Stallknecht

  1. 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 :-)
  2. 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! :-)
  3. 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."

    ------------------------------------------------------

  4. I'm sure this is possible, but it would be difficult to build. Here is my logic:

    You can enable loss of registration emails to send to you every time the phone loses registration. You could send these emails to a script on a server and if you write some sort of script that looks at the percentage of loss of registration emails for the account's devices, you could then have it trigger an API to change a call flow. Of course you'd want to have it double check that the phones haven't all come back online after x minutes, since a brief power outage for example might cause you to receive loss of registration emails for every device even though the devices all come back online minutes later. You would also need to have it check every x minutes to see if the devices had re-registered and thus revert the call flow.

    All of this is doable as far as I can see, but just difficult and would have a lot of moving parts.

    What we do is just have the loss of registration emails get sent into our staff email that is monitored 24/7 and we open a support ticket with the customer asking what to do if we see emails for all of their devices and they are still offline when we check the registrations in Kazoo/Monster. We thought that the "automatic" failover to a cell phone would be a great idea, but it turns out that it wasn't as practical as it seems on the surface:

    1. More often than not the customer will say to just ignore it if it's close to the end of the day or the customer won't care since an answering service will answer the calls as per their regular callflow setup. Keep in mind if the devices are ALL offline (even in a ring group) then it will skip them and go to the next step instantly, so in the case of an answering service it will go straight to the answering service.

    2. Often times the cell phone number that calls should be forwarded to will change depending on who is working that day, meaning you never really know whose cell phone the calls should go to and you need to check with the customer first.

    3. If the customer has no power or no Internet, they often times don't want to answer the phones because they can't do anything after answering them (i.e. look up an order, make an appointment, etc) since their Internet and/or power is down. So they are out of business even if they CAN answer the phone.

    4. Any sort of automatic system could be annoying and go back and forth if the Internet was "flaky" one day. Thus some calls would go to a cell phone and some would go to the desk phone. It's better for this reason to just manually turn it on or off, unless you wrote something to manually turn it on and then require human intervention to turn it off. But again, very minor blips could trigger the forwarding which would get annoying if the customer had to keep contacting someone to disable it.
  5. The problem here is that you can run any kind of test for a week straight and it can look great, and then suddenly the customer can have horrible problems. One of the local ISPs here, Cox, works really well most of the time but still has blips every month or so where calling quality will be terrible for a period of hours or days.

    The Internet is always changing and there are millions of things that can affect Internet quality at someone's location...it's not like a cell phone signal where if you are stationary it will remain the same quality (under normal circumstances).

    Sorry to sound so negative, I just wouldn't advise wasting huge amounts of your time to come up with fancy tests, because chances are you'll just happen to run the test at a time when nothing is wrong thinking the Internet is perfect, and then you'll regret it after installation.
  6. DSL works fine AS LONG AS it's dedicated to the VoIP. For example, several of our customers have Comcast which is notoriously horrible for VoIP. What we do for them is get a secondary internet connection (a DSL line) and connect ONLY their phones to that DSL line. DSL is usually really reliable (at least Verizon DSL in the D.C. area is) but the issue becomes if you connect computers to it too then when they try to download or upload files it sucks up all of the bandwidth which causes call quality issues. Obviously you can implement QoS but in order to do it correctly you need expensive equipment plus then the customer has a horribly slow computer connection. So again, it's easier just to separate the network and have the data network on Comcast/cable and the "voice" network on the Verizon DSL line. That combination makes customers super happy usually, it just involves extra wiring in some situations if they only have one drop per desk/office.
×
×
  • Create New...