On Fri, 2009-06-19 at 14:27 -0400, Joly, Robert (CAR:9D30) wrote: > > > 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.
That seems workable. We probably want a new configuration directive to set the maximum registration time for the NAT case (I'd use 'NAT' in the name rather than 'REMOTE' - the latter could mean just "far away but not behind a NAT", and the issue is the NAT). We may need a different minimum too, since short registrations are a pretty bad thing if everyone is doing them. > > > > > 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. Let's make a note to try to set up a large scale (at least 100's of NATed UAs) test to see if there's an important difference. > > 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. Well, it was worth a try... _______________________________________________ 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/
