Acme Packet 4500
 

PLA-Support>Sun Systems>CommsGBU>Session Delivery Network>SN-SND: Acme Service Provider
 

In this Document

Goal

Solution

Applies to:

Goal

This document explains how the following sip-config options will smooth registration requests over time preventing a CPU spike and call drop scenario when there is a registration storm. This will help prevent the situation of all endpoints continuing to refresh register within the same approximate timeframe. It will prevent the SD from sending too many registers to the core network when SDs cached entry has expired for that AOR.

Solution

max-register-forward =X
The "max-register-forward" option defines a limit of REGISTERs to be forwarded to the registrar. Each second of time, sipd counts how many REGISTERs have been sent to the registrar, it will check the threshold when it receives a REGISTER from the UA and determines that less than half the real registration lifetime is left. If the number of REGISTERs forwarded (new and updates) in the current second exceeds the threshold, it will respond to the UA from the cache. The purpose of this option is to smooth out the message rate to the registrar. An aggressive setting of this value (X) is equal to the registrar's capability (registers/sec); a conservative setting is 75% of that value. Due to the long time to live of REGISTER bindings on the core network (24 hours, with an anticipated refresh after 12 hours by the Session Director), the number of REGISTER messages that the Session Director should forward in any given second is extremely low.

max-register-refresh=X
The "max-register-refresh" option defines the desired limit of REGISTER refreshes from all the UAs. Each second of time, sipd counts the number of REGISTER 200-OK responses sent back. When the threshold is exceeded, it increments the expire time (based on nat-interval) by one second and resets the count. This is an attempt to smooth out the rate of refreshes coming from the UAs. An aggressive setting of this value (X) should roughly equal the number of endpoints divided by the refresh interval; for example, if the box was supporting 12,000 endpoints at a refresh rate of 60 seconds, this would be 200 refreshes per second. A conservative setting increases this value by 150-200%.

register-grace-timer=X
The "register-grace-timer" option defines a grace period before a cached registration is deleted from the SD after it has expired.

reject-register=X
The "reject-register" option defines how REGISTER messages are treated when the CPU is over the limit. A value of "no" will let REGISTERs through to be processed normally despite the Session Director's CPU already being in an overload condition. The value "refresh" lets the REGISTER in, but will check the load limit if there is not a cached registration that it can use for a response. The recommended setting (for value X) is "refresh". This will cause the Session Director to generate a local 200 OK to the REGISTER (easier on CPU consumption) rather than process the entire REGISTER transaction and eventually avoid sending 503s when CPU spikes.

This solution has no attachment