When average processing time is below the normal processing time, then 200 OK response is sent to registration messages.
Regards, _____________ Roman Shpount On Wed, Aug 10, 2016 at 4:22 PM, Michael <n...@spearheadcommunications.ca> wrote: > 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
