

This protection is on by default in Yate and is triggered when the SIP processing engine detects that it handled a configured number of SIP events in a row. Other SIP methods, as well as SIP reINVITES, are still allowed to pass through the filter. When a flood is detected and thus not allowing the creation of a transaction.

The mechanism implemented in Yate acts as a filter which silently drops the following SIP methods: The problem to be solved was providing a way of dealing with flood messages, while not disturbing traffic for already established transactions. The most severe problem when dealing with flood attacks is that they create SIP transactions which can take up system resources to the point where the system becomes unresponsive. The aim of this mechanism was to provide a way of protecting a running system against a flood attack.
