VoIP Firewall Ports Checklist (SIP + NAT)

VoIP Firewall Ports Checklist for Softphones (SIP + NAT)

SIP ports (and the related VoIP / RTP media ranges) are the firewall rules that let softphones and SIP desk phones register, ring, and carry two-way audio through a small-business edge firewall or NAT router. Getting them wrong shows up as failed registration, one-way audio, or “works on mobile data but not in the office.” This playbook is a practical VoIP firewall ports checklist for IT managers at roughly 20–100 person companies: what to allow, how NAT and SIP ALG interfere, how to test before you roll out more seats, and how to keep softphones on sessiontalk.io working without turning the post into a hosted-PBX pitch or a synonym network-QoS rewrite.

What are SIP ports and why do VoIP firewalls care?

SIP ports are the TCP/UDP ports your edge firewall or router uses for Session Initiation Protocol — the signalling that registers a softphone, places and answers calls, and tears them down. Softphones also need a separate media path (usually RTP over UDP) for the actual audio. Both matter: signalling without media is a silent call; media without working signalling never rings.

A VoIP firewall cares because most SMB edges default to “block inbound, allow only a few outbound apps.” Softphones often initiate outbound, which helps, but return traffic, ALG rewrites, and overly narrow media ranges still break calls. Treat voip ports as two families — signalling and media — not one magic number.

This post is about allowlists and NAT, not Wi-Fi tuning. Latency, jitter, and wired-vs-wireless quality live in the VoIP network requirements guide. Keep that lane separate.

Which VoIP ports do softphones usually need (signalling vs media)?

Do not invent a universal global SIP/RTP table. Providers publish different ranges; wrong opens create security risk and can still fail calls. Use the softphone or SIP/ITSP documentation for your path.

• Traffic: SIP signalling — What it does: Register, invite, hang up — Typical starting point (verify): Often TCP/UDP 5060, TLS 5061 — confirm with your provider
• Traffic: Media (RTP / SRTP) — What it does: Two-way audio (and sometimes video) — Typical starting point (verify): Provider-documented UDP range (often wide / ephemeral)
• Traffic: Optional extras — What it does: STUN/TURN, provisioning, push — Typical starting point (verify): Only if your provider lists them

Common practice, not gospel: many SIP stacks use 5060/5061 for signalling. Your cloud PBX, ITSP, or softphone vendor may require others, or may push signalling over TLS on a different port. Copy their published list into your change ticket — then test.

Prefer outbound-initiated softphone sessions from trusted VLANs. Avoid exposing SIP listeners to the public internet on SMB gear unless you fully understand the risk and monitoring.

How does NAT break softphone calls — and what is NAT traversal?

NAT (Network Address Translation) rewrites private LAN addresses to a public IP. Softphones behind NAT often put private addresses inside SIP messages; remote peers then try to send media to an unreachable address. Symptoms: registers fine, rings, then one-way or no audio — or works on mobile data but fails on office Wi-Fi.

NAT traversal is the set of techniques that keep signalling and media reachable across that rewrite: correct firewall allow rules, STUN/TURN when the client supports them, session-border behaviour on the provider side, and avoiding broken helpers like a misbehaving SIP ALG. Double NAT (office router plus ISP modem in router mode) multiplies the problem — fix the topology before chasing exotic port forwards.

If the failure is only behind the office edge, stay on firewall/NAT. Do not blame the softphone app first. Compare an office call against a mobile-data control call after each change.

When should you disable or bypass SIP ALG on the office firewall?

SIP ALG (Application Layer Gateway) — sometimes labelled “SIP fixup” — inspects and rewrites SIP packets. On consumer and some SMB firewalls it often rewrites badly: mangled Contact headers, broken RTP pins, one-way audio after “successful” registration.

Disable or bypass SIP ALG when softphones fail only on the office path, media is one-way, or registration flaps after the ALG is the only recent change. Prefer the vendor’s documented “SIP ALG off” toggle rather than random port forwards.

This checklist owns ports and NAT allowlists. For the diagnose path — captures, one-way audio isolation, ALG confirmation — use the live SIP ALG one-way audio post. Do not merge those deep-dive steps here.

What does a practical VoIP firewall ports checklist look like?

Use this extractable runbook. Adjust port numbers only from provider-published docs.

Document before you change rules

1. List every call path in use: company softphones (sessiontalk.io), any SIP desk phones, and whether calls leave via a cloud PBX/ITSP or a local appliance — do not invent a universal port table; use your provider’s published SIP/RTP ranges.
2. Note the edge device (firewall / UTM / consumer router) and whether staff are behind double NAT (office + ISP modem).
3. Capture a baseline: can a softphone register on office Wi-Fi / wired LAN today? One-way or two-way audio on an internal and an external call?

Allow / shape (keep it minimal)

1. Allow outbound (and return) SIP signalling on the ports your provider documents — commonly TCP/UDP 5060/5061 for SIP, but verify; do not hard-code rival vendor lists.
2. Allow the RTP / media UDP range your provider documents (often a wide ephemeral range) so both directions of audio can pass; if the range is huge, prefer a documented softphone or session-border approach over opening the entire internet.
3. Prefer outbound-initiated softphone sessions from trusted VLANs; avoid exposing SIP listeners to the public internet on SMB gear unless you fully understand the risk.

NAT / ALG hygiene

1. If softphones fail only behind the office firewall, check SIP ALG / “SIP fixup” and disable it when it rewrites packets badly — use the SIP ALG diagnose path for confirmation; this post owns the ports/NAT checklist.
2. Prefer a single NAT boundary; fix double-NAT before chasing exotic port forwards.
3. Keep guest Wi-Fi isolated so unknown devices cannot probe SIP from the guest SSID (see network requirements for QoS / wired vs Wi-Fi — different problem).

Day-one pass/fail test

1. Register one softphone on wired LAN; place an outbound call and confirm two-way audio for ≥30 seconds.
2. Repeat on office Wi-Fi and on mobile data (control): if only the office path fails, stay on firewall/NAT — do not blame the softphone app first.
3. Record the working rule set (ports, ALG off/on, VLAN) in the IT runbook before you add more seats or remote workers.

How do you test registration and two-way audio before rollout?

Treat firewall changes like any other production change: one variable at a time, with a written pass/fail.

1. Baseline — Note current register state and a 30-second two-way audio check on wired LAN.
2. Apply one rule set — Provider SIP ports + media range; ALG off if you suspect rewrite; document the commit.
3. Wired pass — Register → outbound call → two-way audio ≥30s.
4. Wi-Fi pass — Same test on office Wi-Fi (isolates wireless QoS issues from pure port blocks).
5. Mobile-data control — Same softphone on cellular. If only office fails, keep working the edge firewall/NAT.
6. Remote sample — For hybrid staff, spot-check one remote path using your IT manager remote work checklist expectations.
7. Runbook — Save working ports, ALG state, VLAN, and who approved the change. Tie devices to employment with your device onboarding/offboarding process so softphone access follows role, not tribal knowledge.

After the firewall path is clean, day-one app setup is a separate playbook: softphone setup checklist. Policy for personal devices is yet another lane — BYOD softphone policy — not a substitute for port allowlists.

Optional next step once pass/fail is green: company-managed softphones and docs on sessiontalk.io — useful after the edge works, not a shortcut around firewall hygiene.

FAQ

What are SIP ports?

The firewall / router ports used for SIP signalling (call setup, registration, teardown). Softphones also need a separate media (RTP) path for the actual audio — both matter for clear two-way calls.

Which VoIP ports should a small business open?

Use the ranges your softphone or SIP provider publishes (often SIP 5060/5061 plus an RTP UDP range). Do not invent a one-size list; wrong opens create security risk and still fail calls.

Why do softphones work on mobile data but fail in the office?

Often office NAT, SIP ALG, or missing outbound/media rules — not the app. Compare a mobile-data control call against office LAN/Wi-Fi after each firewall change.

Is this the same as VoIP QoS or network requirements?

No. QoS / Wi-Fi / latency-jitter is covered in the live network requirements post. This checklist is firewall ports + NAT so packets are allowed at all.

Where do SessionTalk softphones fit?

Company-managed softphones on sessiontalk.io still need a clean path through the office edge — optional after the pass/fail test, not a hosted-PBX pitch.