I recently saw on a system that people have been abusing 1-800 numbers. They call the 1-800 number, it goes into the FreePBX and then goes to voicemail. Some of the calls to the voicemail are about 12+ hrs in length. This added a few hundred dollars to the clients phone bills. I have since added a maxmessage time to 2 minutes to help mitigate the problem. It would be nice if by default FreePBX came with this set already. Not sure if anyone else has seen this issue?
Perhaps instead of you asking the developers to configure for your application you should earn some of that money you took from the client. Certainly Schmooze didn’t get any.
I really doubt you are being pranked and people are leaving the phone off hook. It’s one of two scenarios:
1 - You don’t have your disconnect set properly and the calls are hanging
2 - You have in call transfer set to work in both directions so you can simply make a phone call from the VM box once they guess the simple password most user utilize.
I’m not sure about your irrelevant and rude comment about Schmooze. In fact we paid Schmooze for support as well as purchased commercial modules. Thank you for the other input though.
I was referring to FreePBX, I would have no knowledge of your business relationship with Schmooze…I should not make assumptions.
Was I correct about the redialing? This is a growing problem I have interest in.
Thanks and sorry for the coarse response. Will you be at FreePBX world next week?
I am not sure if the callers are redialing, as the call log just shows the call trying extensions, and then going into the voicemail. The call originates from the dahdi channels, coming in on the 1-800 number which is forwarded to the main DID See image.
Would like to go to freepbx world, but unfortunately just got back from holidays.
@wrender I am curious about this as well… If we were logged in your deployment should have SSH details. Can you PM me your deployment ID. I would like to look over the logs and see if I can get a grip on their methods. This may help other in the future.
I have experienced that behavior also, and yes they are trying to chew up your 800 minutes, listen to the voicemails, they often are just white-noise, so a combination of limiting the length of a voicemail and a judicious application of adding the culprit (in your case 714912xxxx) to the asteriskdb blacklist when is quite effective, sometimes they come from the same “common-block” unfortunately blacklist can only handle individual numbers.
My guess is with did’s being a dime a dozen and super disposable the blacklist would be of limited value. One successful run can burn a did and leave them plenty of money.
They don’t buy them they spoof them, same as we do every day. But the vector is real, protect yourselves.
I have a few thoughts on defence… Need to get some basic data to confirm my assumptions. I guess I could replicate the attack then defend against it.
if they are pri calls you will need to do that at the libpri level, rdnis et al. by the time they get to dahdi there is little reliable info left
It’s not a PRI. It’s a 24 port analog card. I guess I could still block it at that level?
wow, 24 x even 1MB is cheaper than a PRI?
anyway , you can limit the calls but you need to use
maxsecs=120
and not
maxmessage as your message post header suggests you are attempting ,they are vastly different in effect:-
http://www.asteriskdocs.org/en/3rd_Edition/asterisk-book-html-chunk/Voicemail_id263499.html
OK, it’s not my business but, in 9 out of ten cases, and if you now have a working SIP solution, you should arrange to change the resporg of your toll free number to one that supports SIP, you will almost certainly save yourself a sh*tload. and dump some if not all those expensive FXO’s (you can port all your regular numbers also) but keep one for your alarm circuit.
I experienced the same type of situation with a client system where the time on a call was around 1300 minutes. When the client received their VoIP bill they questioned that call, and when we looked in the CDR’s we found a call wen to voicemail and the person leaving the message left it off the hook.
The client even listened to about 5 minutes of nothingness just to make sure there was nothing valid.
After that we changed the maxmessage value and also the silencethreshold to insure a call like that wouldn’t happen again.
Again to clarify it is NOT maxmessage NOR maxmsg NOR silencethreshold that is pertinent it is maxsecs and maxsilence, attention to detail will prevent misunderstandings and actually work (anyone remember the old adage RTFM ? 
)
Dicko. I believe “maxmessage” is just deprecated but it is the correct setting and I tested it and it ends the voicemail recording after the defined length. So to be more correct I think you are right “maxsecs” should be used instead. I will test to see if “maxsecs” works. Not sure why the deprecated setting is available still in the gui.
the word is actually “deprecated” check your dictionary of choice for what that exactly means
Thanks Dick. Corrected Typo.
+1
Quite confused. 