
Hello Voice-Ops, I have a frustrating situation where a random 1% of PolyCom phones (Mix, but all running 3.1.1) behind EdgeMarcs (VRRP 9.1.9) configuration are losing registrations overnight after a failed boot server check-in. (FTP) Phone will be URL call disabled until reboot or 12 hour+ wait. Inbound calls still work, outbound calls fail. Registration from a packet level is normal. Scenario is complex, but repeatable at multiple client sites. (so not firewall/lan) wireshark, tech support, release codes, ftp logs, and boot logs are all unhelpful/empty, and the firmware code (s) we're running can't be changed without proof, which at this point can only be generated by a fun weekend spent rebooting a cluster of phones over and over again, which for an annoying bug seems excessive. Bit of a rim-rock. Anyone seen anything like this? Cheers, Owen R. ____ Senior Network Engineer Impulse Advanced Communications 805-884-6332 owen at impulse.net

Haven't seen that one with Edgemarcs but see things like that all the time with firewalls. I'd ask the Edgewater support guys if they have heard of the issue, otherwise you will need to get captures of the signaling inside and outside the Edgemarc to see what is causing the problem. If you have EdgeView you can set up a signaling capture easily that can run for a long while and will upload back to the EMS before the ramdrive fills up. Same can be accomplished with a shell script. -Scott -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of owen r Sent: Friday, January 07, 2011 7:59 PM To: voiceops at voiceops.org Subject: [VoiceOps] Combination bug EdgeMarc/Polycom? Hello Voice-Ops, I have a frustrating situation where a random 1% of PolyCom phones (Mix, but all running 3.1.1) behind EdgeMarcs (VRRP 9.1.9) configuration are losing registrations overnight after a failed boot server check-in. (FTP) Phone will be URL call disabled until reboot or 12 hour+ wait. Inbound calls still work, outbound calls fail. Registration from a packet level is normal. Scenario is complex, but repeatable at multiple client sites. (so not firewall/lan) wireshark, tech support, release codes, ftp logs, and boot logs are all unhelpful/empty, and the firmware code (s) we're running can't be changed without proof, which at this point can only be generated by a fun weekend spent rebooting a cluster of phones over and over again, which for an annoying bug seems excessive. Bit of a rim-rock. Anyone seen anything like this? Cheers, Owen R. ____ Senior Network Engineer Impulse Advanced Communications 805-884-6332 owen at impulse.net _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (2)
-
owen@impulse.net
-
scott@sberkman.net