As enterprises are migrating to SIP trunks, they are also often moving to a centralized or regionalized architecture, where the trunks for multiple sites are consolidated into one location (or two for redundancy). As an example, an enterprise with 100 retail sites historically has to purchase less efficient local TDM trunks, such as 1 PRI per site. This can be inefficient – site capacity may occasionally peak close to the capacity of 1 PRI, but on average will be much lower. Usage may be as low as a couple of channels on average. For 100 sites, this represents a lot of unused bandwidth.
By using SIP to combine the trunking at one site, the capacity can be sized to the average needed by all of the sites, plus some reasonable buffer. This allows many fewer sessions to be provisioned. If the average number of sessions per site is 2 and there are 100 sites, 200 sessions could be provisioned and as long as the site peaks and valleys averaged out, this would be enough sessions. Of course this is cutting it too close and most enterprises would provide a buffer, say 400 total sessions, which is considerably less than the total 2300 channels required with dedicated distributed TDM trunking.
From a security point of view, when enterprise “right-sizes” centralized trunking, even with a generous buffer, there are a lot fewer sessions available and the enterprise is more vulnerable to TDoS attacks. There are many fewer available sessions and the enterprise is sort of “putting all their eggs in one basket”. It is simply easier to consume the available capacity. Using my example from above, if the total number of available sessions is 400 and the total allowable per site is 25, and the attack targets 16 sites, they can affect all 100.
Also, if the attacker targets specific sites and can consume all the sessions allowed for those sites, the TDoS bleed over may affect more critical sites, such as a contact center. These sites may be more critical than the actual targets
