Howto:SIP resource allocation
Applies To
This information applies to
- All innovaphone V6 devices
Build 06-6040001 and later if not stated otherwise.
Message allocations
When using UDP as transport protocol for SIP signaling, the SIP user agent (UAC/UAS) is responsible for retransmission in case of packet loss.
For this reason the user agent has to keep transmitted messages (requests or resopnses) to be able to do a re-transmission, in case the remote user agent failed to receive this message. The user agent is obligated to keep transmitted messages for about 32 seconds. (Details: RFC-3261 "SIP: Session Initiation Protocol")
For every non-INVITE transaction the user agent has to save the request and the final response (2 message allocations). For every INVITE transaction the user agent has to save the request, the final response and the ACK (3 message allocations). Our SIP implementation allocates 2KB memory for every single message.
Security considerations
Using UDP as transport protocol for SIP signaling, makes the SIP implementation extremly vulnerable to Denial-of-Service attacks. You just have to send a burst of SIP requests (e.g. REGISTER) to an user agent. No matter if these requests are accepted or rejected, the user agent is obligated to keep all the transmitted responses for 32 seconds. If there is no limitation for message allocations, the system will quickly run out of memory.
To be safe against this kind of attacks, we implemented a limitation for message allocations. Currently we limitate the system wide SIP message allocations to 200. This results in a maximum memory allocation of 400KB. This means that a maximum of 100 ongoing non-INVITE transactions is the limit of the current implementation.
As soon as the allowed amount message allocations are exhausted, the system will stop receiving incoming SIP messages (request or response). The system is going to receive incoming SIP messages again as soon as the number of message allocations drops below the limit of 200 due to timer expiration.
Every discarded message will cause a error message in the trace which looks like this:
SIP: Out of resources: 202 message allocations
Optimizations
REGISTER server transactions
In the special case of incoming REGISTER requests the UAS can do without the ability to differentiate between new requests and retransmissions of previously received requests. Due to this current implementation terminates a REGISTER server transactions immediately after the final response have been sent and frees all associated message allocations.
Non-INVITE client transactions
Note: Implemented in V6 SR2 and later
"Timer K" will be eliminated. The transactions will be deleted right after the reception of the final response and so the accociated message allocations. This violation of RFC-3261 is considered to be harmless, since responses are not retransmitted within Non-INVITE transactions.
(Details: RFC-3261 "SIP: Session Initiation Protocol")