Port 1720 – H.323 (Call Signaling / Q.931)

Port 1720 is the default port for H.323 call signaling — the connection an H.323 endpoint or gateway listens on to set up, negotiate, and tear down voice and video calls. Specifically it carries H.225.0 call control, which reuses the ISDN Q.931 signaling messages (Setup, Alerting, Connect, Release Complete) over TCP. H.323 is the older VoIP and video-conferencing suite that predates SIP, so an open port 1720 almost always means you’ve found a VoIP gateway, IP-PBX, or a video-conferencing endpoint — the kind of device that is interesting both to fingerprint and, if it’s misconfigured, to abuse.

Why It’s Open

H.323 was the dominant VoIP and video signaling standard through the 2000s and never fully disappeared. You’ll find port 1720 on video-conferencing systems (Polycom, Cisco/Tandberg, Sony, Lifesize), IP-PBXs and unified-communications gateways, VoIP-to-PSTN gateways, and older Cisco IOS routers running the H.323 voice feature set. It’s frequently paired with a gatekeeper (which handles admission control and address resolution over H.225 RAS on UDP 1719) and with the H.245 media-control channel that negotiates codecs on a dynamic high port. The actual audio and video then ride RTP, unencrypted unless SRTP is configured.

Where you see 1720, the newer signaling stack is often one scan away — modern deployments have largely moved to SIP on port 5060 and its encrypted variant SIP-TLS on port 5061. H.323 is not SIP: different message formats (ASN.1/PER-encoded Q.931 vs. text SIP), different tooling, different bugs. Don’t point SIP scanners at 1720 and expect results.

Common Risks

• Toll fraud / unauthorized calling. A poorly secured H.323 gateway that bridges to the PSTN lets an attacker place calls through it — premium-rate or international numbers billed to the victim. This is the classic, expensive real-world impact of an exposed VoIP gateway.
• Auto-answer eavesdropping. Many video endpoints ship with auto-answer enabled. An attacker who can reach 1720 places a call, the system answers silently, and the attacker gets live audio and video of the room — often with remote pan/tilt/zoom control of the camera.
• Endpoint and gatekeeper enumeration. The call-setup exchange leaks vendor, product, firmware version, and Caller ID / DisplayName; gatekeeper registration (RRQ/ARQ) can reveal aliases, extensions, and E.164 numbers.
• Media interception. H.323 media is RTP, cleartext unless SRTP is negotiated — call audio and video can be reconstructed from a capture.
• Implementation bugs (DoS/RCE). H.323 stacks have a long history of memory-safety flaws. The PROTOS/OUSPG H.225 test suite (2004) crashed or owned a wide range of vendor stacks; several Cisco IOS and Microsoft ISA Server bugs trace directly to it.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and version

nmap -sV -p 1720 <target>

Nmap’s version detection has real H.323 probes — it fingerprints OpenH323 / GNU Gatekeeper, Cisco Unified Communications Manager gatekeepers, and Polycom ViewStation endpoints straight from the Q.931 response.

Grab the raw banner

nmap -p 1720 --script banner <target>

H.323 version and vendor scan with Metasploit

msfconsole -q
use auxiliary/scanner/h323/h323_version
set RHOSTS <target>
run

This module (default RPORT 1720) places a probe call and reads back the protocol version and Vendor ID, and for most devices the Product ID and DisplayName / Caller ID — a fast way to inventory H.323 systems across a range. (Note: h323-version is this Metasploit module, not an nmap NSE script — nmap ships no h323-* script, so use -sV for nmap-side detection.)

Confirm the port and capture the exchange

nc -nv <target> 1720

Q.931 is binary, so a netcat connect mainly confirms the port is open — run the setup exchange under Wireshark / tshark and let the H.225 / Q.931 / H.245 dissectors decode vendor, version, aliases, and negotiated codecs.

Log every open 1720, every vendor/version string, and any endpoint that auto-answers so the evidence lands in the pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

• CVE-2003-0819 — Buffer overflow in the H.323 filter of Microsoft ISA Server 2000, remote code execution in the Firewall Service via crafted H.323 traffic, demonstrated with the NISCC/OUSPG PROTOS H.225 test suite. CVSS v2 10.0 (unauthenticated RCE). Patched in MS04-001 — the marquee PROTOS-class result.
• CVE-2004-0054 — Multiple vulnerabilities in the H.323 implementation of Cisco IOS 11.3T–12.2T; remote DoS and possibly code execution, also flagged by the PROTOS H.225 suite (NISCC 006489). CVSS v2 7.5.
• CVE-2020-14305 — Out-of-bounds write in the Linux kernel’s H.323 connection-tracking (nf_conntrack_h323) handling connections on IPv6 port 1720; an unauthenticated remote attacker can crash the host. CVSS v3.1 8.1 (DoS).
• CVE-2011-3277 — Cisco IOS / IOS XE NAT implementation reloads the device on crafted H.323 packets to TCP 1720. CVSS v2 7.8 (DoS).
• CVE-2010-0582 — Cisco IOS H.323 handling wedges the interface input queue on malformed H.323 packets. CVSS v2 7.8 (DoS).
• CVE-2010-0583 — Memory leak in the Cisco IOS H.323 implementation; malformed packets drive memory consumption and a device reload. CVSS v2 7.8 (DoS).
• CVE-2009-2866 — Cisco IOS 12.2–12.4 reloads on a crafted H.323 packet. CVSS v2 7.8 (DoS).

The takeaway: most public H.323 CVEs are denial-of-service against network gateways (heavily Cisco IOS), with the two PROTOS-class Microsoft/Cisco bugs the standout code-execution cases. Anything running an H.323 stack from the 2000s should be treated as fragile against malformed input.

Mitigation

• Don’t expose 1720 to the internet. Firewall H.323 signaling to trusted VoIP peers and management ranges only; there is rarely a reason for a video endpoint or gateway to answer the whole internet.
• Disable H.323 if you run SIP. Many devices enable both stacks by default — turn off the one you don’t use and confirm 1720 is closed on a rescan.
• Turn off auto-answer on video endpoints, or scope it to known internal peers, so a stranger’s call can’t open the room.
• Require gatekeeper authentication and lock registration/admission (RRQ/ARQ) to known endpoints to block rogue registration and enumeration.
• Lock down PSTN dial-out. Enforce calling privileges, destination allow-lists, and rate/anomaly monitoring on any gateway that reaches a trunk — this is what stops toll fraud.
• Encrypt where supported. Use H.235 / TLS for signaling and SRTP for media so call content isn’t sniffable.
• Patch the stack. Keep Cisco IOS, the ISA/firewall H.323 filter, the Linux kernel, and endpoint firmware current — the CVEs above are all patched.

Real-World Example

In January 2012, HD Moore and Rapid7 scanned about 3% of the addressable internet for H.323 on port 1720 and found roughly 250,000 systems, of which just under 5,000 were set to auto-answer incoming calls — extrapolating to an estimated 150,000 exposed, auto-answering video systems worldwide, before counting internal corporate networks. The split was largely by vendor default: Polycom shipped auto-answer enabled, while Sony, Tandberg (Cisco), Lifesize, and Codian required it to be turned on. Because H.323 doesn’t traverse standard firewalls cleanly, organizations often placed these units straight on the public internet. The team demonstrated dialing into unattended boardrooms and, with remote camera control, reading a six-digit password off a sticky note more than 20 feet away and watching keyboards and laptop screens. It’s a clean illustration that the risk on 1720 isn’t only a crash CVE — a default-on setting plus internet exposure is enough to turn a conference room into an open microphone and camera. (The auxiliary/scanner/h323/h323_version Metasploit module used to inventory those systems is authored by the same researcher.)

FAQ

What is port 1720 used for?

Port 1720/TCP is the default port for H.323 call signaling — the H.225.0 call-control channel, built on ISDN Q.931 messages, that sets up and tears down VoIP and video-conferencing calls. It’s the signaling front door for H.323 gateways, IP-PBXs, and video endpoints; the media itself rides RTP on separate ports.

Is port 1720 dangerous?

It’s risky when exposed. An internet-facing 1720 can leak vendor and firmware details, let an attacker place unauthorized (toll-fraud) calls through a gateway, silently auto-answer a call into a room for eavesdropping, and — on old stacks — be crashed or exploited by malformed H.323 packets. Keep it on internal or trusted-peer networks.

What is the difference between port 1720 and port 5060?

Both set up VoIP calls, but they’re different protocols. Port 1720 is H.323 (binary ASN.1/Q.931 signaling, the older ITU-T suite); port 5060 is SIP (text-based, the modern standard). They use different tooling and have different vulnerabilities — SIP scanners like SIPVicious don’t work against H.323 on 1720.

How do I secure or close port 1720?

Firewall 1720 to trusted VoIP peers, disable H.323 on devices that use SIP instead, turn off auto-answer, require gatekeeper authentication, restrict PSTN dial-out to stop toll fraud, enable H.235/TLS and SRTP where supported, and patch the gateway or endpoint firmware. If nothing needs H.323, disable it and confirm the port is closed with nmap -p 1720 <target>.

TL;DR

• Service: H.323 call signaling (H.225.0 / Q.931) — legacy VoIP and video-conferencing signaling
• Default port: 1720/TCP (gatekeeper RAS on UDP 1719; media over RTP; media control via H.245)
• Biggest risks: toll fraud on exposed gateways, auto-answer eavesdropping on video endpoints, and DoS/RCE bugs in old H.323 stacks (Cisco IOS, MS ISA Server, Linux kernel)
• Mitigation: keep 1720 off the internet, disable H.323 if you use SIP (5060), kill auto-answer, authenticate the gatekeeper, lock PSTN dial-out, and patch the stack