Can someone explain this to me?

The system is a Freepbx distro with 5.211.65 upgrading now to -100. They have a T1 Pri the digium driver is Over the weekend the T1 provider noticed MANY calls going international, so they blocked international calls. There were several hundred. Here is a single record from that time:

2015-05-23 06:52:40 1432378360.744454 98924XXXXX Wait s [from-digital] ANSWERED 01:55

There are no entries in either the Outbound Callerid or the DID. The puzzling thing is the destination as from-digital. To my knowledge there are no SIP ports forwarded to the system, they do have a trunk to a distant location over IAX. I checked that system and there are no calls in the CRD during those times. In the system with the PRI there are no outbound routes that allow international calling.

Could some one be using the PRI itself to call out?

Has anyone encountered anything like this?

Leakage into a dhadi channel is very unlikely, Look at the lines immediately preceding the dahdi call in your logs, both the voicemail system and allowing “in-call forwarding” of any type are likely candidates for the origination of those calls, a tip would also be to enable dtmf logging.

Thanks Dicko I will look in those places

I haven’t looked in the logs yet, but I see in the Global settings for the DAHDI card. 3 way calling, call waiting, transfer, call forwarding, and call return are all enabled. Probably not a good thing huh?

Argh, The logs end 20 minutes after the problem occurred. The system starts the logs on sunday morning (at least they started at 8:30 am) and the issue went from 6:40 to 8:10. I created a DTMF log report. So we will see.

there are more generally more than one log file maintained depending on how lograte is setup on your system.

ls -lsrt /var/log/asterisk/full*

The initial problem happened BEFORE the call, so investigate the file that is timewise appropriate

Country code 989 is a mobile phone in Iran, areacode 989 is in Michigan, you need to discover what mechanism was used to initiate the underlying call, my guess just slack security measures.

Audit your system, ref:-

to find out who is trying to do what to whom.

I could add to that that post that on your trunk both limit “Asterisk Trunk Dial Options” almost certainly you should NEVER have “T” there. Also limit outbound call routes that start with your local version of +(international) (in NANP land that is “011” ) to only allow appropriate MSD’s , 01144 for the UK (or indeed 011[34] (Europe in general) , possibly ok, be careful of the Eastern countries , on the other hand 011970 for Palestine or 01186 (China) , probably NOT OK :wink:

For how MSD (Most Significant Digit) dialing works check

The CDR didn’t show where the calls were going, I got the called numbers from the PRI provider. I don’t have them in front of me at the moment but the majority of them were to country code 37, from what I found out that is for the old Esat German block of countries. I got into the system and the oldest log file is as I indicated before. There are no international dial rules and none that use a +.
Here are my dial rules
NXXXXXX prepend is 1989

I have a outbound rule for 911 and 311

I will audit the system as you suggest.

The CDR’s wont, the log file likely will.

The logfiles do not go back far enough. They start an hour and a half “after” the incursion ended. So I have nothing to look at.

Then you shouldn’t have changed the standard logrotate settings. it would have been in full.1