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

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

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/674... 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