200 MOR can't determine who is calling

SYSTEM ERROR. CODE 200. The system cannot determine who is calling.

The IP from which the call comes is not entered in the system or is entered incorrectly. 
Some other fields in configuration may also be missing. 
Please consult the online manual at wiki.kolmisoft.com.

What are these calls? Where they are coming from?

It is either

• attempt of your Provider/Customer which authentication is not properly configured (see the section below in such case);
• automated scanners looking for vulnerable systems that would allow the call to pass without proper authentication (which MOR is not).

Source IP address of certain call can be seen in Call Info page "Originator" section.

I do not recognize the source IP address of these calls. Does that mean my system is hacked?

No. These calls are rejected by MOR and cannot pass, because only calls from authenticated sources (registered or IP authenticated Devices/Providers) are allowed to pass.

Why these calls are shown among the rest of the calls?

Because all calls are shown for troubleshooting and informational purposes. In case your User or Provider does not complete authentication, its call would be rejected with the same HGC 200. Such CDR would provide an indication of authentication problems.

I do not want to see these calls, how to block them?

By default, the fail2ban service installed in the MOR system blocks the source IP of calls with code 200 if the same IP places 20 attempts in 10 minutes.

In addition, if the source IP of these calls is not from your business countries, you can block those countries using Blocked Countries.

The above measures might greatly reduce the number of such calls, but there will still be some left. At least a minimal amount to trigger fail2ban protection. That is normal and not harmful as calls are not allowed to pass.

I see HGC200 on attempt to place call from my Provider/Device

• Check settings for Provider/Device.
• For provider - make sure hostname and IP address have correct values.
  • Both these fields should be filled.
  • If hostname is not assigned, then it should have an IP address, with the same value as the IP address field.
• Check the port setting.
  • The call may not be coming through the default SIP port 5060, but from 5061. Check this.
  • Port refers to the SOURCE port. That means the port the call is coming FROM, not the port it is coming TO.
• Make sure that originator is using same protocol as it is configured in Device/Provider in MOR. Means, make sure that it is not trying to make H323 call while Device created in MOR is SIP type.
• If you are using H323 in file h323.conf, add UserByAlias=no.
• If you are using ZAP/H323 provider, you may have forgotten about the accountcode=X setting. (More info)
• Make sure accountcode for dialing device is not 0 (ERROR[3433]: app_mor_authentication.c:11 mor_get_user_by_acc: Accountcode cannot be 0!)

The most common reason

You forget to describe IP in MOR from which the call is coming.

Example:

[Dec 17 08:37:42] WARNING[21726]: app_mor.c:3557 mor_get_user_by_acc: User not found by accountcode:
[Dec 17 08:37:42] ERROR[21726]: app_mor.c:667 mor_authorize: MOR can't determine who is calling. Make sure accountcode is set for caller (Provider or Device).
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:692 mor_authorize: Caller type: Local
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:706 mor_authorize: Localized destination: 5143161536
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3872 process_sipchaninfo: ============== SIPCHANINFO ===============
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3897 process_sipchaninfo: Peer IP: 64.34.135.88
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3898 process_sipchaninfo: Source IP: 64.34.135.88
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3899 process_sipchaninfo: From: sip:7052058393@64.34.164.254
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3900 process_sipchaninfo: Contact: sip:7052058393@64.34.164.254
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3901 process_sipchaninfo: Useragent: Voice Network Inc 1b
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3902 process_sipchaninfo: Peername:
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3903 process_sipchaninfo: T38Passthrough: 0
[Dec 17 08:37:42] NOTICE[21726]: app_mor.c:3907 process_sipchaninfo: ==========================================

The above means that MOR does not know about IP 64.34.135.88.

SOLUTION: assign this IP to some Provider (or Device) in MOR.

The most common reason why people get this error

The reason is, that very often MOR administrators forget about Trustrpid, Sendrpid, Insecure: port/invite options in device settings window. They must match incoming call settings. The image below shows settings that are usually correct.

These options should be enabled on IP authenticated Device/Provider only. Do not enable these options on Username/Password authenticated Devices.

Hacking

When your server goes online - instantly it will be detected by the IP scanners and Hackers will start to send various calls probing your system for vulnerabilities. You will see such probes as HGC 200 calls.

Correct Action Sequence in such situation:

1. Check Call Info of such calls to see from which IP calls are originated
2. If IP is not one of your Providers or Clients - Block it.

Why the system is not blocking such calls automatically? - System blocks such calls when there are 15 such attempts per hour.
If a hacker sends less than 15 such probing calls per hour - the system will ignore such calls.
This can be adjusted by Kolmisoft engineers - please let us know if you want to block such calls faster.
15 calls/hour is configured intentionally not to block valid call attempts from your Clients who have trouble configuring their phones.

How to disable such call attempts

By default MOR allows guest calls (unauthenticated calls) so the calls would be processed and would show up in the STATISTICS->Calls->Last Calls after they are rejected and the Admin could see such call attempts as well. This is very useful when you are trying to setup a new device and the call does not go through due to bad authentication. However, you can disallow such calls to be processed at all by changing the "allowguest" option in sip.con file. To do so, simply open the sip.conf file with any editor(in the example we will be using "vi")

vi /etc/asterisk/sip.conf

Then find the allowguest option and change it to:

allowguest=no

After this save the file and reload asterisk so new setting would take affect:

asterisk -rx 'sip reload'

See also

• Hangupcause Codes