Dear all,
 
 
>Kaplan, Michael A wrote:
> Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear > in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
>
IETF RFC 6357 "Design Considerations for Session Initiation Protocol (SIP) Overload Control"
Can be found in the following link.
http://tools.ietf.org/rfc/rfc6357.txt
 
Please note that mechanisms for the server to advertise to upstream neighbors to reduce request rates must modify SIP header. This is called "Explicit Overload Control Feedback" in RFC6357. Unfortunately Changing the SIP header requires a time-consuming standardization process, because all the SIP servers from different service providers in different countries have to implement new SIP with new headers. 
 
 
 
>Kaplan, Michael A wrote:
>Some of the other overload control mechanisms described in the RFC (e.g. window based control and loss based control) would also be of interest to me. Not sure if public implementations exist or if they are restricted to research implementations.
Yes. "Explicit Overload Control Feedback" proposed by RFC6357 are restricted to research implementations. Public implementations require cooperation from all the service providers of SIP. However, implicit overload control does not require any modification of SIP header and time-consuming standardization process. Any SIP server can implement implicit overload control.
 
 
>Alex Balashov wrote:
>You can always construct such a reply yourself, and append headers to it.
Yes. But appending headerers requires RFC standardization process and cooperation from all the service providers of SIP at different countries all over the world.

 
From FRC 6357, "The main difference between explicit and implicit overload control is the way overload is signaled from a SIP server that is reaching overload condition to its upstream neighbors. ...... Implicit overload control uses the absence of responses and packet loss as an indication of overload. "
The Central Weather Bureau of Taiwan has implemented implicit SIP overload control algorithm in their early earthquake warning system with SIP, as shown by the paper "An Efficient Earthquake Early Warning Message Delivery Algorithm Using an in Time Control-Theoretic Approach" in the following link.
http://www.springerlink.com/content/b6252x2k613rv211/?MUD=MP
 
 
We have implemented three different types of implicit SIP overload control algorithms using OPNET simulator (http://www.opnet.com/). Our OPNET codes are available for non-commerical use or open-source project upon request. Please note that implicit SIP overload control algorithms only rely on the feekback of "200 OK"  messages, therefore, they do not require any modification on SIP header or RFC standardization process.
 
 
We have published an exhaustic literature survey on explicit and implicit SIP overload control up to the related publications until March 2011, because the submission deadline of book chapter was March 2011. The original draft of our book chapter "A Comparative Study of SIP Overload Control Algorithms" is available free of charge for non-commerical use or open-source project upon request.
http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67496
 
 
If any software engineers want to implement implicit SIP overload control in either Kamailio or OpenSIPs, I can cooperate with them for software implementation. Currently I am a software engineer for cloud web service.
http://www.inbaytech.com/products.html
 
 
Best regards,
 
Yang 
 
> From: mkaplan@appcomsci.com
> To: sr-users@lists.sip-router.org
> Date: Thu, 26 Jul 2012 15:37:40 +0000
> Subject: Re: [SR-Users] Overload Control
>
> Thanks, this is very much what I was looking for. It appears the ratelimit/piplimit modules offer some degree of overload control through queue drops and invite rejections based on a server's local cpu load. Some of the other overload control mechanisms described in the RFC (e.g. window based control and loss based control) would also be of interest to me. Not sure if public implementations exist or if they are restricted to research implementations. Thanks for the pointer to ratelimit nevertheless.
>
>
> -----Original Message-----
> From: sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov
> Sent: Wednesday, July 25, 2012 2:39 PM
> To: sr-users@lists.sip-router.org
> Subject: Re: [SR-Users] Overload Control
>
> But also, check out this module:
>
> http://www.kamailio.org/docs/modules/3.3.x/modules/pipelimit.html
>
> On 07/25/2012 02:33 PM, Kaplan, Michael A wrote:
>
> > Sure - I'm referring to mechanisms for the server to advertise to upstream neighbors to reduce request rates. This could include methods that appear in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement). I suppose the try-again-after method would be of interest as well.
> >
> >
> > -----Original Message-----
> > From: sr-users-bounces@lists.sip-router.org
> > [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex
> > Balashov
> > Sent: Wednesday, July 25, 2012 2:29 PM
> > To: sr-users@lists.sip-router.org
> > Subject: Re: [SR-Users] Overload Control
> >
> > Can you elaborate as to what you mean by that term, "overload control"?
> >
> > On 07/25/2012 01:49 PM, Kaplan, Michael A wrote:
> >
> >> Folks,
> >>
> >> I'm trying to figure out if either Kamailio or OpenSIPs provides the
> >> various overload control algorithms recommended in the IETF or
> >> elsewhere. I haven't found documentation to this effect. Has anyone
> >> looked into this or used such techniques?
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >>
> >>
> >> _______________________________________________
> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> >> list sr-users@lists.sip-router.org
> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >
> >
> > --
> > Alex Balashov - Principal
> > Evariste Systems LLC
> > 235 E Ponce de Leon Ave
> > Suite 106
> > Decatur, GA 30030
> > Tel: +1-678-954-0670
> > Fax: +1-404-961-1892
> > Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> > list sr-users@lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> > list sr-users@lists.sip-router.org
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
>
>
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur, GA 30030
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users