When the initial registration time is met, what code is send out from your proxy server?
Sent from my iPhone > On Aug 10, 2016, at 11:40 AM, Roman Shpount <[email protected]> wrote: > > Hi Paul, > > When dealing with a similar problem we have approached it on our edge > proxies similar to traffic flow queuing disciplines (GRED to be precise). > An edge proxy would measure average registration processing time for a back > end registration server. When average processing time exceeds the normal > processing time limit (100 ms in our case), the edge proxy will start > randomly refusing a gradually increasing percentage of the registration > messages. When average processing time exceeds the overload processing time > limit (250 ms in our case), the edge proxy will refuse all registration > messages. When registration messages were refused, proxy would send a 500 > error response with Retry-After header set to a random value between 30 and > 60 s. > > Regards, > _____________ > Roman Shpount > > On Wed, Aug 10, 2016 at 11:00 AM, Paul Kyzivat <[email protected]> > wrote: > >> I refreshed my memory on that draft. It proposes a new header field for >> the registrar to tell the UA what to do after a failure. That may indeed be >> necessary for an ideal solution. >> >> Does anyone know of a documented approach using only *existing* sip >> features? >> >> Thanks, >> Paul >> >> >>> On 8/10/16 10:45 AM, Paul Kyzivat wrote: >>> >>> Thanks to Volkan and Brett for this reference. I'll review it. >>> >>> Anybody else have something different? >>> >>> Thanks, >>> Paul >>> >>>> On 8/10/16 10:35 AM, Brett Tate wrote: >>>> >>>> Hi Paul, >>>> >>>> The topic is discussed within draft-shen-soc-avalanche-restart-overload; >>>> however I don't recall why the draft didn't progress further within >>>> soc or >>>> dispatch. >>>> >>>> -----Original Message----- >>>>> From: [email protected] [mailto:sip- >>>>> [email protected]] On Behalf Of Paul Kyzivat >>>>> Sent: Wednesday, August 10, 2016 10:08 AM >>>>> To: [email protected] >>>>> Subject: [Sip-implementors] backoff algorithms to prevent registration >>>>> storms? >>>>> >>>>> Strategies for preventing registration storms (e.g., after a major power >>>>> outage and recovery) have been discussed from time to time. >>>>> >>>>> Can anyone point me to specific documentation of such schemes? Ideally a >>>> spec >>>> >>>>> that can be referenced, but failing that I'll be happy with pointers to >>>>> thorough email discussions or non-standard implementations. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> Sip-implementors mailing list >>>>> [email protected] >>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
