As per Net::Server documentation, override "options" to provide your own custom options to the Net::Server* object. This allows us to use the Net::Server infrastructure for configuration rather than hacking our own configuration into the object.
As per Net::Server documentation, this method validates our custom configuration.
This hook occurs after the client connection socket is created, which gives us an opportunity to enable support for TCP keepalives using the SO_KEEPALIVE socket option.
By default, the kernel-level defaults (in seconds) are used. You can view these in the output of "sysctl -a": net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_time = 7200
Alternatively, you can use "custom_tcp_keepalive_time" and "custom_tcp_keepalive_intvl" to define your own custom values for the socket. Note that these parameters are defined at the top server-level and not on the listener-level.
If you lower "custom_tcp_keepalive_time" below 75, you will also need to set "custom_tcp_keepalive_intvl". The "tcp_keepalive_time" is the initial time used for the keepalive timer, and the "tcp_keepalive_intvl" is the time used for subsequent keepalive timers. However, timers only send keepalive ACKs if the idle time elapsed is greater than "tcp_keepalive_time".
Thus, if "tcp_keepalive_time = 10" and "tcp_keepalive_intvl = 5", a keepalive ACK will be sent every 10 seconds of idle time. If "tcp_keepalive_intvl = 10" and "tcp_keepalive_time = 5", a keepalive ACK will be sent after 5 seconds of idle time, and the next keepalive ACK will be sent after 10 seconds of idle time. Generally speaking, it's best to set "tcp_keepalive_time" to be higher than "tcp_keepalive_intvl".
Reminder: once these settings are set on the socket, they are handled by the operating system kernel, and not by the SIP server application. If you are having trouble with your settings, monitor your TCP traffic using a tool such as "tcpdump" to review and refine how they work.
$server->_config_up_to_date();
Check if the configuration is up to date. Returns 1 if the configuration is up to date, 0 otherwise.
This method is used to check if the configuration stored in the database is different from the one stored in the object. If the configuration in the database is newer, the method returns 0 and the object must be updated.
process_request is the callback used by Net::Server to handle an incoming connection request.
Manages the SIP login process for raw TCP connections. Clears any previous session state, applies a timeout, reads the initial request, and authenticates it. On success, sets up logging context and enters the SIP protocol loop. Returns on EOF, timeout, or failed login.
Cleans a string by removing leading and trailing non-alphanumeric characters. Logs the string before and after cleaning, or notes if the input was undefined. Returns the cleaned string (or undef if no string was provided).
Reads a single line from STDIN, normalizes it using get_clean_string, and discards any additional input lines, logging them as errors. Returns the cleaned input line.
Handles the login process for terminals connecting via the telnet transport. Prompts for a username and password, applies a timeout to protect against hung connections, and validates the credentials against configured accounts. On successful authentication, initializes the SIP session by invoking sip_protocol_loop. Dies on timeout or repeated failed login attempts.
The terminal has logged in, using either the SIP login process over a raw socket, or via the pseudo-unix login provided by the telnet transport. From that point on, both the raw and the telnet processes are the same:
Reads a single SIP request line from STDIN using carriage return as the record separator. Strips leading and trailing non-alphanumeric characters, removes extra line breaks, and logs any trimming that occurs. Also flushes Level-1 caches before processing each request. Returns the cleaned request string, or undef on EOF.
$server->get_timeout({ $type => 1, fallback => $fallback });
where $type is transport | client | policy
Centralizes all timeout logic. Transport refers to login process, client to active connections. Policy timeout is transaction timeout (used in ACS status message).
Fallback is optional. If you do not pass transport, client or policy, you will get fallback or hardcoded default.