Well, that protection mechanism to avoid surf registration load to SIPX is understood. That seems a pretty wise fence.
My another question is how&when SIPX knows to give phones by random registration timers ? -----Original Message----- From: WORLEY, Dale R (Dale) [mailto:dwor...@avaya.com] Sent: Thursday, July 08, 2010 9:23 AM To: Wen Jun; sipx-users@list.sipfoundry.org Cc: 'jun,wen' Subject: RE: [sipx-users] Expires discrepancy of bulk registration by SIPP ________________________________________ From: sipx-users-boun...@list.sipfoundry.org [sipx-users-boun...@list.sipfoundry.org] On Behalf Of Wen Jun [jun.wen.s...@gmail.com] I made 100 subs to initiate registration from SIPP to SIPX with "expires: 300" inside SIP Invite. Whereas, I observed in SIPX the expire timers of all these 100 subs varies from hundreds to thousands. What I expected should be same 300 seconds of each subs in expires. _______________________________________________ Well, you can't do registration with INVITE. But sipXecs has a design feature, where the length of registration that it grants for a REGISTER request is randomly shorter than the length of registration that is requested. (It is never longer, as that is forbidden by RFC 3261.) The reason for this is to prevent a problem when the power comes on in a building: All the phones boot up at the same time and register in a crunch, causing excessive load on the server. There is nothing that can be done about that. But we wish to prevent a crunch happening an hour later, when all the phones' expirations expire. (The commonest registration request is for 1 hour.) So sipXecs grants each phone a randomized fraction of its requested registration. The initial crunch isn't cured, but there is no crunch a hour later. Dale _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
