Back


SROP:
Cache-challenges
Reg-overload-protect
max-register-forward=X
max-register-refresh=X
register-grace-timer=X
reject-register=refresh

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.

Reg-overload-protect
    When enabled the SD  temporarily promotes the address of the SIP endpoint to a trusted access-control level when it receives
the 401/407 response (to the first REGISTER request) from the registrar.  The purpose of the temporary promotion is to ensure that
the second REGISTER (with authentication credentials) can reach the SD.
The promotion lasts for a short period of time equal to the remaining expiration time of the REGISTER server transaction plus
the value of the trans-expire parameter of the sip-config.