Vg7 With Hmp Driver: Calls Busy For All The Lines (Answ: Voip Dos Atta

[iTime]

Hello,

 

one of Our customers has reported that the IVR server was busy for all the lines when they called in, but we could not find the cause.

This is HMP + VG7 (custom version).

I attach the log file and this problem started from the line (I think):

 

090125.555 6 13 4 state <offered> : cid=785xxxxxxx@208.93.227.xxx , dnis=785xxxxxxx@192.168.100.131
090125.555 6 13 4 AnswerTheCallIfAllowed 8000004, iIvrDev=4, strDlgcDevName_Network=iptB1T4
090125.555 6 13 4 rings=0, min rings before answer=2 (iCallerIdHasArrived=1)

 

 

From this point, you can see that the log shows the very similar contents as above until the end (we restarted the server after that and it is fine now)

 

If you can let us know what was causing this issue, that will be much appreciated.

 

Thank you.

 

CallsBusy.zip

[SupportTeam]

Trace shows that all calls that arrived at the system were answered and taken through the script.

 

You would be able to use WireShark to confirm that all SIP 'INVITES' arriving at the system are answered.

 

On VoIP systems the cause of the problem could be the network - with packets not getting through due to congestion or routing misconfiguration on the network carrying the VoIP traffic.

090125.555  6  13   4 state <offered> : cid=785xxxxxxx@208.93.227.217 , dnis=785xxxxxxx@192.168.100.131
090125.611 18  13   4 ev    Dialogic 2050,GCEV_ANSWERED, crn=8000004, 2050,0,0,,,
090126.806  6  13   4 state [PlayWelcomeGetEmpNumber] Playing wav (WAV Files\Welcome_01.wav,WAV Files\Welcome_02.wav)
090133.301 18  13   4 ev    dtmf 5   (134217732,53,7)
090133.963 18  13   4 ev    dtmf 4   (134217732,52,8)
090134.564 18  13   4 ev    dtmf #   (134217732,35,7)


091533.590  6  19   6 state <offered> : cid=785xxxxxxx@208.93.227.217 , dnis=785xxxxxxx@192.168.100.131
091533.662 18  19   6 ev    Dialogic 2050,GCEV_ANSWERED, crn=8000006, 2050,0,0,,,
091534.868  6  19   6 state [PlayWelcomeGetEmpNumber] Playing wav (WAV Files\Welcome_01.wav,WAV Files\Welcome_02.wav)
091546.694 18  19   6 ev    dtmf 9   (134217734,57,11)
091547.092 18  19   6 ev    dtmf 2   (134217734,50,10)

[iTime]

I may have picked up an event that was OK

.

I found out that whenever you see (towards the end of the log),

state <offered> : cid=100@192.168.100.131

 

The call did not make it. Instead, it opens up another port until all the ports are tied with this number. (I do not know why these calls show "100" for the CallerID)

I guess it was taken care by your earlier patch (that is included in our custom VG7), but it is coming back?

[SupportTeam]

ktTel trace shows that someone or some program has launched a simple denial of service attack on your VoIP system.

 

This is what can happen if your network is not locked down and secured against such things.

 

Below is the list of CallerIDs of 'bad' calls arriving into your system. As you can see 11 SIP INVITES were sent to your system in the 8 seconds between 09:35:07 and 09:35:15

 

The IVR system sends an acceptance message to 192.168.100.13 but no call is ever established, and channels are then used up until the system times out.

 

This will happen again unless your network is secured. Traces show other similar calls later in the day.

 

A simple way to protect against it to start the script 'before answering the call' and check in script if the CallerID ends in "208.93.227.217". If it does not then hang up the call - without ever attempting to answer it.

 

If you network is not secured against such attacks then you will probably get more sophisticated attacks later on - eg. ones that pretend to come from valid IP addresses/numbers.

 

No such denial of service attacks happen on ISDN trunks...

19981:552 093507.907  3828  37       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=996edabb]
20020:591 093508.887  3828   3       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=a89bba54]
20059:630 093510.064  3828  16       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=e02746b1]
20098:669 093510.836  3828  34       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=22aa6eb0]
20137:708 093511.175  3828  10       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=9fb33c4d]
20176:747 093511.988  3828  13       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=2c6979bd]
20215:786 093512.802  3828  19       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=47dd3d51]
20254:825 093513.165  3828  22       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=de179935]
20293:864 093514.314  3828  28       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=a48bedd2]
20332:903 093514.827  3828   7       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=ff80cbab]
20371:942 093515.956  3828  31       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=b9ba3f94]


26018:153 125002.213  2784  37       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:7000@192.168.100.131;tag=65d8fdc7]

26951:086 135847.542  2784  10       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=f9700c29]

27453:588 142901.476  2784  16       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=dfdaec5f]

29695:830 150642.990  2784  31       gc_GetCallInfo ORIGINATION_ADDRESS_SIP=[sip:100@192.168.100.131;tag=d35c0a90]

The channels that were answering these DOS calls reset themselves after 2 minutes of waiting, and were then ready to answer any new incoming calls. No calls were seen being presented to the IVR system though till system was reset about an hour later.

 

To track down what happened to calls during that hour would involve using WireShark to track whether the VoIP IP packets arrived on system and/or if any other applications ended up being installed on system that intercepted these IP packets, etc.

 

As mentioned before, ISDN and Analog systems do not have these problems of viruses and other malicious software that interfere with IP traffic.

[iTime]

I see.

I will try to set the firewall with the given IP ranges by the service provider then.

Thanks.