Technical Summary:
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document defines the protocol for communicating overload information
between SIP servers and clients, so that clients can reduce the
volume of traffic sent to overloaded servers, avoiding congestion
collapse and increasing useful throughput.
Working Group Summary:
This document was originally started by an ad-hoc Design Team within
the SIPPING wg. The document was then adopted by the SIP Overload
Control WG once it has been created.
There has been 13 versions of the document of the document since it
has?been adopted as WG item, and the document has passed two
WGLC?one in March 2012
(http://www.ietf.org/mail-archive/web/sip-overload/current/msg00731.html)
and a second one in February 2013
(http://www.ietf.org/mail-archive/web/sip-overload/current/msg00911.html).
All the issues and the feedback raised have been addressed, and the
wg is now happy with the status.
Document Quality:
Are there existing implementations of the protocol?
I am not aware of any.
Have a significant number of vendors indicated their plan to implement
the specification?
Yes, all the major vendors have indicated they have a plan to
implement it.
Moreover also 3GPP is supporting it and it will be referenced in its
spec.
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?
No
Personnel:
Who is the Document Shepherd?
Salvatore Loreto <salvatore.loreto@ericsson.com>
Who is the Responsible Area Director?
Richard Barnes <rlb@ipv.sx>