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.