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
wrote:
> When the initial registration time is met, what code is send out from your
> proxy serv
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 wrote:
>
> Hi Paul,
>
> When dealing with a similar problem we have approached it on our edge
> proxies similar to traffic flow queuing di
Paul,
I have mentioned this to your before, we also did registration message
caching in our edge proxies to reduce the load on the back end registration
servers. In our particular deployment, we did not show all the
registrations for the AOR to the end point and we could cash the client
credential
Roman,
Interesting. That takes the load off the registrars, but the edge
proxies still must handle it.
Thanks,
Paul
On 8/10/16 1:40 PM, Roman Shpount wrote:
Hi Paul,
When dealing with a similar problem we have approached it on our edge
proxies similar to traffic flow queuing
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 nor
Hi,
RFC 5626 Appendix A discusses an algorithm.
The soc working group RFCs provide some additional algorithms from an
overload perspective.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of
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
Paul Kyzivat writes:
> 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
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
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.c
https://tools.ietf.org/html/draft-shen-sipping-avalanche-restart-overload-01
2016-08-10 17:07 GMT+03:00 Paul Kyzivat :
> 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 docum
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 em
12 matches
Mail list logo
