Jump to content

sporkman

Members
  • Posts

    26
  • Joined

  • Last visited

  • Days Won

    1

Recent Profile Visitors

956 profile views
  1. Can you tell me what version you're running? I have a VVX410 running 5.5.1.15937. This article was updated to note some issues were corrected after 5.4.0: https://community.polycom.com/t5/VoIP-SIP-Phones/FAQ-How-can-I-create-a-local-directory-or-what-is-the/m-p/74922/highlight/true#M14125 The old behavior was for the phone to copy the global directory to the personal directory, making them semi-permanent.
  2. I have a phone sitting here and both it's shared directory file (000000000000-directory.xml) and the per-phone directory file (64167f94XXXX-directory.xml) are empty and after multiple reboots, the phone just holds on for dear life to the previous contents of those files. Going to try different levels of phone resets to see which one finally makes it ask for either of those files again. Trying to imagine doing a reset on an office with like 50 phones just to update the contacts...
  3. I am overjoyed. LDAP sucks on Polycoms, a static file "sticks" in the phone until you do a full reset, and per-user directories are terrible. Can you share what underlying feature in the Poly's you're using to achieve this?
  4. And if anyone was wondering, I was going to try the "learn by doing" approach, but whatever I was putting in for names/numbers was just always giving me an error. I assume I'm misunderstanding what goes in what field or what's allowed in each field. Anyhow, I guess this was taken away as the option no longer shows up:
  5. Anyone? I would be very thrilled if this actually generated a contact list that polycom phones could use in some way...
  6. Are there any docs describing what this part of the Advanced Provisioner does?
  7. Yes, the call center issue. It's a very large ob/gyn office. I mean, not having ladies in labor being able to reach their nurse or doctor is a really big deal - in many ways this client is probably more demanding than an office full of traders. Total disaster. And the hours spent convincing our reseller there was a problem, just painful. Even after the fix, there are still ongoing issues that I suspect don't show up in lower call-volume queues, and definitely some browser-specific issues with the web app that we never really nailed down.
  8. And... that call center app failure lost us the customer. Misplaced optimism. Think twice about "mission critical" customers on the platform.
  9. Yeah, maybe misplaced. It's a huge ob/gyn office and the call center app is hugely not functioning. You want to up the stress level in an office like that? Get your phone system dumping calls from ladies in labor. Huge black eye for us and a bit of a "is this ready for prime time" sort of moment.
  10. I think I see what you're looking at then - an unprovisioned phone is going to be generating many more 404s than a provisioned phone? When we bring up a large number 40-100, is there a batch size we can work with that won't trigger this? The method of having the DHCP server set the boot server saves literally hours of work compared to entering stuff by hand on every phone, especially if you're going into an office and transferring phones from another provider. DDoS generator attached:
  11. Thanks! So my remaining question is what happens in a more normal situation like a power outage where you similarly have an inrush of phones looking to hit the server? Will they be blocked?
  12. We use DHCP option 66 to provision new phones to the zswitch server. This is obviously way faster than manually keying the provisioning server into each phone and it works great with new phones. For used phones, we similarly point all the phones at Polycom's boot server which clears and updates them if necessary. Today we were on site with 70 phones to provision. After a round of 30 or so phones, we found no further phones could be provisioned. After much troubleshooting, we realized that "p3.zswitch.net" was not reachable from our public IP at this site. We flipped to another public IP and were able to do another batch of phones. Then same thing, "p3.zswitch.net" becomes unreachable. My spidey sense says that there's some kind of DDoS protection in place and turning up an office full of phones at once is triggering it. This is worrisome in that a) we should be able to bulk provision phones and b) would this same thing happen if, say a large office lost power and then all the phones hit the server at once when the power returned we'd be in a similar situation Thoughts?
  13. I'm not sure how useful this would be to advanced users or how often it would be useful, but in trying to sort out all the various config files served up, overrides in the Advanced Provisioner, etc. I find I can waste an ungodly amount of time doing something simple like trying to grab all the config files a particular phone wants to load. For troubleshooting, I find it useful to grab the configs sometimes. For the learning process, seeing a list of the files (and the order they're loaded) is handy. I'm talking all Polycom here, but I assume other phones are similar. What I'd like to see in the Advanced Provisioner is some data that's probably already there being exposed on one of the config tabs. Mainly a list of config files, in the order they're read, all with hyperlinks to the actual config files. Make sense?
×
×
  • Create New...