Latest revision as of 15:20, 19 February 2026

ERROR: Unknown caller. No matching device found in the system.

What does HGC 200 mean?

HGC 200 means that MOR received a call attempt but could not match it to any existing Device or Provider.

In simple terms: MOR does not know who is calling because the incoming IP / port / protocol does not match your configuration.

This does not automatically mean your system is hacked.

Quick 5-Minute Check (Start Here)

Before reading further, follow this checklist:

Go to Last Calls Open the failed call Click Call Info Find Originator → Source IP

Now answer this question:

Do you recognize this IP address?

Yes → Go to Setup problem

No → Go to Internet scanners

I just want to stop seeing these calls → Go to Reduce noise

Why These Calls Appear in MOR

MOR displays all call attempts, including rejected ones.

These calls are shown:

So you can diagnose configuration mistakes
So you can see authentication problems
So you can monitor suspicious traffic

If MOR cannot match the call to a Device or Provider, it rejects it with HGC 200.

If You Are Setting Up a New Device or Provider

This is the most common reason for HGC 200.

It usually means that the authentication settings do not match.

Check the following:

1. IP Address / Hostname

Open your Device or Provider configuration.

Make sure the IP field matches the Source IP shown in Call Info.

If Hostname is used, ensure it resolves correctly.

If you do not use Hostname, it should match the IP.

Mismatch here is the most common cause.

2. Source Port

The default SIP port is 5060.

However, some providers or devices use:

5061

custom ports

Important: The port must match the port from which the call is actually coming.

Check the Source Port in Call Info.

3. Protocol Type

Verify that:

SIP calls are configured as SIP
H323 calls are configured as H323

If protocol types do not match, MOR cannot identify the caller.

If You Do NOT Recognize the Source IP

If the IP address is unknown to you, most likely, you are seeing random Internet SIP scanning. This is normal for any public VoIP server.

Important facts:

These calls are rejected.
They cannot pass without proper authentication.
HGC 200 means MOR blocked them.
This does NOT mean your system is compromised.

Correct Action Sequence for Unknown IP

Identify Source IP in Call Info Confirm it does not belong to your customer or provider Decide whether to block it or ignore it

You have options:

Block IP manually
Use fail2ban
Use Blocked Countries feature
Leave it as is (safe but visible)

How to Reduce or Block Such Calls

If your goal is simply to reduce noise:

Option 1 – Use fail2ban (Recommended)

fail2ban automatically blocks IP addresses after repeated failed attempts.

Default behavior: 20 attempts within 10 minutes - IP gets blocked

This is the safest automatic solution.

Option 2 – Block Specific IP

You can manually block suspicious IP addresses at firewall level.

Option 3 – Disable Guest Calls (Advanced)

You may disable unauthenticated calls in Asterisk configuration:

allowguest=no

Warning:

This prevents unknown calls from reaching MOR.

It may make troubleshooting harder.

New devices may fail silently if misconfigured.

Only change this if you understand the impact.

Frequently Asked Questions

I do not recognize the source IP. Is my system hacked?

No.

If calls are rejected with HGC 200, it means MOR is protecting your system by refusing unidentified calls.

Why are these calls shown among normal calls?

Because MOR logs all attempts for diagnostic purposes.

Without these logs, you would not be able to identify configuration errors.

I just connected a new client, and calls fail immediately

Most likely:

Wrong IP
Wrong port
Wrong protocol
NAT issue

Start from the 5-Minute Check at the top of this page.

Glossary (Simple Definitions)

HGC 200 MOR could not match the caller to a configured Device or Provider.

Source IP The IP address from which the call attempt was received.

Device An endpoint (phone, PBX, gateway) configured in MOR.

Provider An upstream carrier or trunk configured in MOR.

fail2ban A service that automatically blocks IPs after repeated failed attempts.

Summary

HGC 200 means MOR does not recognize the caller.

In most cases, it is:

A configuration mismatch (when setting up new connections) OR

Internet scanning (harmless but noisy)

Start by checking the Source IP.

That single step usually determines the correct next action.

Important note

In older MOR versions, the log may show the following message:

ERROR: MOR can't determine who is calling. Make sure accountcode is set for caller (Provider or Device).

Please note that you cannot directly change the accountcode for a Device or Provider. Therefore, this message can be misleading.

Instead of trying to modify the accountcode manually, you must properly configure the Device or Provider (for example, IP address, authentication, or related settings) so that MOR can correctly identify the caller and automatically assign the appropriate accountcode to the incoming call.

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:

Check Call Info of such calls to see from which IP calls are originated
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'

Difference between revisions of "200 MOR can't determine who is calling"