SIP trunk congestion

[handwritten]

We have 2 MCD instances recently upgraded to 7.0PR1, with SIP trunks going through Mitel Border Gateway boxes.  We have a sporadic ring-no-answer on incoming calls, which began after we upgraded from an earlier release (6.something, I think).  There should be no reason for higher than average call volume, because this is our low season.  We noticed a very high number of calls coming into various DID numbers that point to Cisco SPA-112 ATAs serving fax machines.  See the SMDR log for an example of these calls.  We believe the high volume of calls is causing congestion on the SIP trunks, which results in the ring-no-answer on incoming calls.  However, it's very suspicious that the problems began after the software upgrade.  Any thoughts would be highly appreciated! 

Code: [Select]

08/01 06:15P 00:00:03 T889  *** 774201                                         
           1234567890 774201                                                   
 08/01 06:15P 00:00:02 T889  *** 774201                                         
           1234567890 774201                                                   
 08/01 06:15P 00:00:03 T889  *** 774201                                         
           234567890  774201                                                   
 08/01 06:15P 00:00:02 T889  *** 774201                                         
           234567890  774201                                                   
 08/01 06:15P 00:00:03 T889  *** 774201                                         
           234567890  774201                                                   
 08/01 06:15P 00:00:03 T889  *** 774201                                         
           234567890  774201                                                   
 08/01 06:15P 00:00:02 T889  *** 774201                                         
           1234567890 774201                                                   
 08/01 06:15P 00:00:03 T889  *** 774201                                         
           1234567890 774201                                                   
 08/01 06:15P 00:00:03 T889  *** 774201                                         
           1234567890 774201                                                   



[ralph]

Do a SMDR search for "E".  Do you see a lot of them?   

[handwritten]

I see three today, and three on Friday.

Code: [Select]

08/05 12:22P 00:00:00 X999  *** 1207                      E                   
 08/05 10:47A 00:00:00 X999  *** 9416960                   E                   
 08/05 09:02A 00:00:03 T889  ***                           E                   
 08/01 06:41P 00:00:02 T889  ***                           E                   
 08/01 06:35P 00:00:03 T889  ***                           E                   
 08/01 06:22P 00:00:03 T889  ***                           E                   
LOGSYS info: READ completed for SMDR log with 1000 entries.                     


[handwritten]

I searched farther back, and log goes back to July 25.  Since then there have been 138 calls with the E.  From the documentation, I see that this means there was an error with the call.

[ralph]

From the documentation, I see that this means there was an error with the call.

What that can also mean is that someone is trying to hack your system.
Do a search on this forum for "SIPVicious".

I've seen something similar to what you described on two different sites.
The SIP address was publicly accessible so it opened up for a hack attempt.   The "E" means that a number was dialed (or trunk seized without dialing anything) but the number was invalid.

Ralph

[handwritten]

Ok, I'll look into that.  Thanks very much, Ralph!

[handwritten]

This may or may not be related.  I was looking at the calls in progress, and I noticed that while most of the calls were tagged with my [SIP Provider's IP], some were tagged with [some other IP] - see below.  Shouldn't the 3300 only see the IP of my provider?  I thought the provider routed all calls through their equipment.

3) Link: ACI Profile: SIPTrunk ID: 11d96370(774)-10028036
 1-Active 1-Associated Sessions Started at THU AUG 07 16:37:07 2014
 Calling: 4169776000@[SIP Provider's IP]
 Called: 4168995841@[SIP Provider's IP]
 MediaState: StateMediaAnswered (1,17)
 State: StateEstablished
 Call-ID: 224769984-104155098
 IDs: obj=efce app=2 timer=108ad810 chal=0 incp=0
 auth=0 cpn=0 rt=0 ssdp=0 tc=0 cong=0 ansr=0
 outpend=0 inpend=0 outtone=0 sdpType=0 winfo=0 tdown=0
 SSPc=0 MHc=0 cc=1
 ReferTo:  ReferBy:
  Media Audio sendrecv Remote IP:[MBG proxy IP]:24978 Local IP:[set device IP]:50094

4) Link: ACI_2 Profile: SIPTRK2 ID: 11d8d470(584)-8640
 1-Active 1-Associated Sessions Started at THU AUG 07 16:20:38 2014
 Calling: 6596451157@[some other IP]
 Called: 1175@[some other IP]
 MediaState: StateMediaAnswered (1,17)
 State: StateEstablished
 Call-ID: 3725482-3616431525-359977@sbc02-b.defaultdomain
 IDs: obj=ef59 app=2 timer=10cdfa80 chal=0 incp=0
 auth=0 cpn=1 rt=0 ssdp=0 tc=0 cong=0 ansr=0
 outpend=0 inpend=0 outtone=0 sdpType=0 winfo=0 tdown=0
 SSPc=0 MHc=0 cc=1
 ReferTo:  ReferBy:
  Media Audio sendrecv Remote IP:[MBG proxy IP]:24838 Local IP:[set device IP]:50298

[ralph]

Can you tell if these are valid calls?
Or are they to VM or something else?

You should probably call your carrier and have a discussion on this.   In theory it may just be call routing within the carriers network.   However it could also be a hack attempt and you'll need to lock down your local router to only accept SIP request from your carriers network.

Ralph