Ghost calls — the phone rings, no one is there, the caller ID often shows 100 or 1000 or some random extension — are almost always SIP scanner traffic from the public internet. The fix is at the network edge, not the phone. Letting them pass through to the PBX is the real problem.
Ghost calls are unsolicited SIP INVITEs sent to your phones from the public internet. The classic symptom is a desk phone ringing with caller ID showing 100, 1000, sipvicious, friendly-scanner, or some other suspicious string. Picking up reveals dead air or no audio at all. The call duration is usually one or two seconds before the scanner tears down the call and moves on.
The traffic is generated by automated scanners crawling the public IP space looking for open SIP endpoints. The most well-known is sipvicious (now ancient but still active under various derivatives), but there are dozens of these scanners running continuously, mostly looking for endpoints they can use for toll fraud.
The phone rings because it is configured to accept SIP INVITEs from any source on UDP 5060. The scanner finds the public IP, sends an INVITE, and the phone rings. The user experiences this as a phantom call.
For a ghost call to ring a phone, several network conditions must be met:
Most consumer routers and many small business firewalls have SIP ALG enabled, which keeps a NAT pinhole open on UDP 5060 after the phone registers. Scanners discover the open pinhole and send INVITEs through it. The SIP ALG forwards them to the phone.
Direct public exposure of phones is also more common than it should be. SOHO setups with port forwarding rules, cloud-hosted softphones, and misconfigured firewalls all produce this.
Ghost call traffic has consistent fingerprints in a SIP trace:
The right place to block ghost calls is at the network edge, before they reach any SIP endpoint. The configuration depends on your environment:
If you have a SIP trunk from a specific carrier (Twilio, Bandwidth, Telnyx, Flowroute, etc.), restrict UDP 5060 inbound to only those carrier IP ranges. Every legitimate provider publishes their SIP IP allowlists. Block all other sources at the firewall.
Phones registering to a hosted PBX should not need any inbound SIP from the internet. The phone initiates the registration, NAT keeps the path open, and inbound calls arrive on the existing SIP dialog. Block UDP 5060 inbound entirely.
If your PBX is on a public IP and accepts inbound from carriers and remote phones, use IP allowlisting plus rate limiting. Tools like fail2ban can dynamically block source IPs that fail authentication too many times.
Disable SIP ALG on the firewall regardless of the above. SIP ALG is responsible for many of the mishandled NAT scenarios that expose phones to scanners in the first place.
If firewall-level blocking is not feasible, the next layer is the PBX itself.
In pjsip.conf, set endpoint_identifier_order=ip,username and define endpoints with match= matching only your trunk provider's IPs. Anything that does not match a defined endpoint is rejected. Set allowguest=no in the global PJSIP context.
Use fail2ban with the asterisk filter to dynamically ban source IPs that send unauthenticated INVITEs.
In the SIP profile, set auth-calls=true to require authentication on all INVITEs. Use acl.conf.xml to define a domains list and reject anything not in it. fail2ban filters for FreeSWITCH are widely available.
Use the permissions module with an address table containing trusted source IPs. Reject INVITEs from unknown sources at the start of the request_route. Use pike module for rate limiting per source IP.
Most SBCs (AudioCodes, Ribbon, Oracle, Sansay) have built-in topology hiding and ACL features. The SBC should be the only thing exposed to the public internet, and its ACLs should restrict inbound SIP to trusted carrier ranges.
Phone-side blocking is the last resort but worth knowing:
If ghost calls persist after firewall and PBX-level fixes, the phone is reachable via a path you have not closed. Audit network paths and NAT rules until the unauthenticated traffic stops at the perimeter.
Ghost calls are unsolicited SIP INVITEs sent to your phones from automated scanners crawling the public internet. The phone rings because it accepts INVITEs from any source on UDP 5060. The caller is usually a tool like sipvicious, friendly-scanner, or sipcli running on a cheap cloud VM looking for open SIP endpoints to use for toll fraud.
Block at the network edge first. If you use a SIP trunk provider, restrict UDP 5060 inbound to only their IP ranges and disable SIP ALG on the firewall. If you have a hosted PBX, block UDP 5060 inbound entirely — phones initiate registration outbound and inbound calls arrive on the existing dialog. PBX-level blocking with fail2ban and IP allowlisting is the second layer. Phone-side mitigations are a last resort.
The 100 or 1000 caller ID is a fingerprint of SIP scanner traffic. Tools like sipvicious enumerate common extension numbers (100, 1000, 999) when sending unsolicited INVITEs to find configured trunks. Real callers do not present these numbers. If you see this caller ID, the phone is reachable from the public internet and being scanned. Block UDP 5060 inbound at the firewall.
Paste your SIP trace into SIPSymposium. The analyzer identifies scanner User-Agent strings, suspicious source IPs, and the exact INVITE patterns that produce ghost calls.