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
