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 <[email protected]> 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 <[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
