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 <ro...@telurix.com> 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 <pkyzi...@alum.mit.edu> > 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: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >>>>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat >>>>> Sent: Wednesday, August 10, 2016 10:08 AM >>>>> To: Sip-implementors@lists.cs.columbia.edu >>>>> 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 >>>>> Sip-implementors@lists.cs.columbia.edu >>>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
