On Fri, 2009-06-19 at 13:41 -0400, Robert Joly wrote: > Folks, > Whenever a remote worker registers with wipXecs, the sipXproxy process > will start maintaining the pinhole to the remote worker by sending an > OPTIONS message every 20 seconds. This process ensures that the > firewall & NAT in front of the remote worker will accept and forward > incoming requests from sipXecs. Without that process, the firewall > would close the pinhole some time after the phone's last transmission. > > Recently, we have experienced some problems in the lab whereby > restarting the sipXproxy process can interrupt the generation of > pinhole-maintaining OPTIONS messages for up to 3 minutes. This > interruption is enough for many firewalls to close their pinholes > rendering the phones behind them unreachable from the POV of sipXecs. > This situation heals itself the next time the remote phone refreshes its > registration but because sipXecs's max expiry value is one hour, a > remote phone can lose its ability to receive incoming for a full hour > following a sipXproxy restart. > > To solve this situation, I can see two approaches which are not mutually > exclusive: > > 1- for remote phones that support a SIP keepalive feature, that feature > should be turned on;
Obviously a good idea, assuming that what the phones do is itself reasonable (hopefully they just send a CRLF every so often - that being much cheaper than a SIP request). > 2- sipXecs should significantly reduce the maximum registration expiry > for remote phones to something like 5 minutes. How would you propose that the registry recognize that a phone needs this shortened registration period? > The latter would increase the work load of sipXecs but would ensure that > every phone returns to a fully functional state within 5 minutes of a > system reboot, sipXproxy reboot or network outage. I'm not too > concerned about the increased work load - here is why. Earlier this > year I was doing performance measurements on sipXecs and as part of my > test setup, I had to register 5400 users very often. I had a SIPP > script that was doing the bulk registration at a rate of 100reg/sec and > the system could very easily cope with such a load... Was that an HA system? Isn't there a third case - for phones using UDP at least, the proxy could persist the keepalive targets so that it could start sending to them after a restart. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
