Why are we wasting system and network resources to be polite to Anonymous SIP calls when "No" is set in General Settings?

Before I open an official bug on this I wanted to see what other people thought.

As far as I’m concerned, if I select “No” for “Allow Anonymous SIP Calls” in the General Settings page that means I don’t care one single little tiny bit about anonymous SIP calls.

Why does FreePBX Answer(), Playbback(ss-noservice), Congestion(), and finally Hangup()?

Just to be perfectly clear about what we are doing here, we are allocating memory and resources for a SIP call we don’t care about, using I/O to read a file from the hard drive, using bandwidth to stream the audio in both directions (probably in µLaw) then we send the congestion tone and hang up the channel.

What happens when someone uses sipp or sip vicious to spawn 100 simultaneous anonymous calls to a system that has anonymous SIP calls disabled? Well, it allocates the resources, answers the calls and chokes your 1.5Mbps DSL connection with calls you don’t care about.

I propose we simplify that entire process down to a simple Congestion(), Hangup(). We 503 the call without ever accepting one bit of audio path, without reading a sound file from the hard drive, no transcoding, nothing more than sending a simple, tiny SIP response saying “I can’t do anything for you”. We let the originating system use their resources playing back their copy of “ss-noservice” or the congestion indication or whatever their end is set up for in the case of a 503.

So, am I missing something obvious here? Is there a reason we politely answer the call (which is wrong anyway since we should use early media to stream error messages) then play back an informative audio file (that the malicious script on the other end of the line won’t care one bit about), and only then terminate the call with a 503? In my opinion sending the 503 is already going above and beyond considering the fact that it is for a call that is unsolicited, unwanted and in the end probably malicious. The response itself could expose information about the system from a security standpoint.

If others are in agreement I will submit a bug report and a patch for the proposed changes.

if you are particularly concerned, you may want to use a firewall to block unauthorized IP addresses which would be the most efficient way of handling it.

There are also SIP settings that you can set so that it doesn’t accept any calls vs. going to the default context that does what you describe.

As far as why it is like it is and should it change, it’s a valid question. If it is for the sake of ‘attacks’ then it’s best handled outside of Asterisk with a firewall. If it’s for concern of a few cycles now and then, I think that is of minimal concern.

However, there are other ways of handling the calls if anonymous is turned off which are worth discussing if others want to pipe in. As far as the current way of handling it, it can actually be quite helpful in many debugging situations when people are bringing up new carriers and running into issues because of mis-configurations.