Jump to content

Karl Stallknecht

Members
  • Posts

    1,141
  • Joined

  • Days Won

    21

Everything posted by Karl Stallknecht

  1. This has always been the case for us - if we call a client we hear our own hold music (not theirs), and vice versa.
  2. Uh oh, this is really important to us too! Are you noticing that accounts you used to set to 3600 are now going back to the default, or you just can't change newly created call recording objects?
  3. So it looks like the failover was added? But it's listed under the number manager? I'm confused on how exactly this works...
  4. I guess I don't really see a way that this could practically work, that's the thing...right now we just contact customers manually when we receive loss of registration email(s) for them. Sometimes they want us to forward and sometimes they don't want us to depending on the time of day, who is working, what else is going on, etc. Basically what I am saying is that I personally don't think it is worth spending time/money building this feature if it would be impractical. I see a lot of people jumping on board with it at first, and then realizing it's not as simple as it sounds and there are too many caveats. But this is just my opinion :-)
  5. @Darren: Let's say the customer's Internet is going in and out constantly one day. This feature you mentioned would cause some calls to still go to their desk phones which might be a bad idea because the call could cut out or have poor quality. So this means that the customer would have to manually enable call forwarding always (or the "* Forward all calls" option you listed above as the proposed setting) in order to make everything go to their cell phone. The phone(s) could signal a loss of registration for many reasons, and sometimes we even see customers have loss of registration emails get triggered but no noticeable outage took place, so this would unnecessarily send a call here and there to the cell phone.
  6. Agreed Rick.  My other concern here is a lot of our customers with crappy Internet lose registration constantly, so this would cause incoming calls to keep going back and forth between their desk phone and cell phone constantly and it would get annoying for the customer.
  7. Whoops, I guess we made a slight oversight. It actually looks like some of our phones that were provisioned a long time ago using Kazoo are still pointing to 184.x.x.174 manually (non-DNS). Is there a way to push an update out? We really don't have time between now and December 2nd to finish switching everyone over to Monster/advanced provisioner.
  8. Are the IPs going out of service that you listed in your email all proxy IPs? I noticed we had 209.x.x.233 and 184.x.x.174 listed in some DNS records of ours related to SIP proxies/what our SIP realms are pointed to, so we replaced them with 166.x.x.67 and 8.x.x.3, respectively. Just wanted to make sure this was okay to do. **FYI 209.x.x.233 is still listed in Monster under DNS Helper as the "general proxy fallback" but you said in your email that this IP is going bye bye...is this a mistake on the email or does it need to be removed from Monster? I know you don't want us sharing the IPs publicly, so I intentionally was vague. Let me know if you want us to directly email you with the exact IPs.
  9. The default password pulled from the provisioner is 2600. You can change this in advanced provisioner provider settings.
  10. You're right about the NAPTR records not being supported on DNS Made Easy. I figured that between our own DNS and DNS Made Easy, the likelihood of specifically 2600hz's east coast proxy having an outage at the same time as our own DNS servers is pretty low so I just took a chance when setting it up. So technically speaking if our DNS servers go down then the NAPTR records won't work, but Polycoms at least will fall back to A records, which WILL be up via DNS Made Easy: http://support.polycom.com/global/documents/support/technical/products/voice/SIP_Server_Fallback_TB5... (see page 5) If other phones such as Yealinks or Cisco don't fail back to A records then that would cause a problem of course. And if 2600hz's east coast proxy went down when our DNS was also down, then it wouldn't fail over to central or west coast. But again, the likelihood is all of those things happening at once is pretty low. All of this being said, we aren't even using hostnames yet for any live clients. But once we get transitioned to Monster then what I have mentioned above will apply.
  11. Regarding DYN: yep! It was actually kind of nice considering we a) don't use them for anything and b) are using IPs. Not a single complaint from a single customer that day :-) That being said, we always recommend using multiple DNS providers which apparently now 2600hz is going to be implementing. We run our own DNS servers as well as use DNS Made Easy. Having both us and them go down would pretty much be impossible and I was shocked that 2600hz didn't have a similar setup to be honest considering it's cheap and easy to have multiple DNS providers.
  12. Rick: I doubt that will help - we actually are still using IPs instead of hostnames since we're still 100% on Kazoo and the old provisioner. Esoare: Hmm, interesting. Our customers are on a very wide variety of equipment, but most of them are using their ISP's default modem/router. The BLF problems seem to come and go and aren't constant which made me think it wasn't likely to be an issue with their equipment. Also, last week as an example we had one customer on FiOS and one customer on Cox (one of the local cable companies) both simultaneously complaining that they were experiencing BLF issues in the same exact behavior.
  13. This infuriates us/our customers to no end. Last week we had multiple customers complaining and all we were told from 2600hz support was to flush the BLF data and let them know if it happens again (which it did). We haven't received any complaints today, but honestly I think a lot of our customers get sick of it and just stop reporting it to us since it's such a frequent occurrence.
  14. This is a 2600hz bug that they apparently have patched but not put into production yet.
  15. Can you please post the recording here? I won't be available.
  16. No. I had two phones. Both had it enabled. One of the phones (random one, not always the same one) would show the missed calls and the other wouldn't. But NEITHER of those two phones answered the calls - it was always another employee on a different phone. So theoretically, neither of those phones should have showed missed calls but often times one would and one wouldn't. They are all Polycom. What happens if a non-supported phone answers the call? Will the supported phones still hide the missed call? I'm assuming the answer is yes in this manner, just not the other way around.
  17. Yes I know, both phones were configured with it enabled. Devices are Karl Home and Karl Office. I ended up turning it off because it got confusing to have one phone showing the missed calls and the other phone not showing the missed calls. You're welcome to place test calls but my home phone is currently in a box somewhere since I moved recently.
  18. Okay so here's what we experience: We have a ring group for our "support" line being an option from our IVR menu. I have two phones (one at the office and one at home) and usually I don't answer the support calls and instead my employees do. I will often notice that one of my phones will show missed calls that were answered by other employees, but my other phone won't show the missed calls - but it seems random as to when or why it happens. And it's not always one phone or the other that shows the missed calls versus not shows the missed calls.
  19. I've never been able to get this to work :-/
×
×
  • Create New...