> 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 registry already has to do some trickery for NAT compensation when dealing with a remote worker and that is to remove the address mapping annotations we made to the Contact so that the UAC sees the Contact it expects in the 200 OK (XX-5926). In a similar fashion we could use the REMOTE_WORKER upper bound instead of the default one when we detect remote workers. > > > 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? It wasn't. > > 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. The pinholes are already persisted for UDP. The issue is that a sipXproxy restart momentarily interrupts the generation of pinhole-maintaining OPTIONS long enough for some firewalls to close the pinhole. When sipXproxy eventually comes back, it resumes the generation of OPTIONS where it left it based on persisted data but it is already too late in many cases as the pinhole is already closed. _______________________________________________ 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/
