SIP Trunk Security Best Practices for Dealers 

---

Most SIP trunk security failures trace back to firewall decisions made during installation, not to sophisticated attacks.

• Port 5060 is heavily scanned, so signaling belongs restricted to your provider’s gateway addresses rather than opened broadly.
• SIP ALG is the most common cause of one-way audio and dropped calls, and disabling it resolves a large share of post-installation tickets.
• Media behaves differently from signaling and must be accepted from any source address, which is where careful dealers over-tighten and break audio.
• Toll fraud exposure compounds across a portfolio, so controls belong in your onboarding template rather than applied account by account.

Treat security configuration as a repeatable onboarding process, and it stops being a support cost and starts becoming a reason customers renew.

---

If you resell voice services, security configuration is where your technical reputation is made or lost. The SIP trunk security best practices below are written for the person doing the installing and supporting, not the end user reading a glossary. They assume you manage several accounts, inherit networks you did not build, and need repeatable answers rather than theory.

Federal agencies published communications infrastructure hardening guidance in late 2024 after threat actors compromised major telecommunications networks. Its recommendations map directly onto voice deployments: default-deny access control lists, network segmentation, no default passwords, and encrypted transport. Those principles scale down cleanly to a 30-seat PBX behind a small business firewall. A proven SIP trunk reseller platform removes the carrier-side burden, but the customer edge is yours to configure.

Why Do SIP Trunk Security Best Practices Start Before Installation Day?

Almost every problem you will troubleshoot later is visible during discovery if you know what to ask. A pre-installation checklist takes 20 minutes, prevents the emergency call three weeks after cutover, and doubles as a professional artifact you can hand to the customer’s IT contact.

What Should You Verify About the Customer Network?

Start with the connection. Confirm whether the customer has a static or dynamic public IP, since that determines how the PBX registers and whether IP-based authentication is an option. Ask who administers the firewall because “our IT guy” and “the cable company installed it” lead to very different timelines.

Then map the edge: firewall make and model, whether SIP-aware inspection is enabled, and whether voice shares a subnet with workstations and guest Wi-Fi. Flat networks are workable but raise the blast radius if any endpoint is compromised. If the customer will put phones on a dedicated VLAN, take that offer.

What Should You Verify About the PBX and Endpoints?

Confirm the PBX platform, firmware version, and whether it still receives vendor support. An unsupported system is a conversation to have before you sell the trunk, not after. Check whether default administrator credentials remain in place because they frequently do. Understand how SIP trunking works on that platform, since RTP handling varies between systems.

Here is the checklist worth running on every account before provisioning:

1. Public IP confirmed as static, or a registration-based plan documented if it is dynamic.
2. Firewall model identified and administrative access confirmed with the responsible party.
3. Any SIP inspection, SIP transformation, or VoIP profile feature located in the firewall interface.
4. PBX firmware confirmed current and under active vendor support.
5. Default administrator and extension passwords replaced with strong, unique credentials.
6. PBX management interfaces confirmed as unreachable from the public internet.
7. Long-distance and premium-rate dialing permissions defined in writing before cutover.

That last item matters more than it looks. Sign-off on dialing permissions before cutover turns a future fraud incident from a dispute into a documented decision.

Which SIP Ports and RTP Port Range Need to Be Open?

SIP trunking uses two traffic types with genuinely different security requirements, and treating them identically causes most configuration failures. Signaling should be tightly restricted. Media should not be.

Port	Protocol	Purpose	Recommended handling
5060	UDP	Standard SIP signaling	Restrict to provider gateway addresses only
5060	TCP	SIP over TCP, used when messages exceed UDP packet size	Restrict to provider gateway addresses only
5061	TCP	SIP over TLS, encrypted signaling	Restrict to provider gateway addresses only
5160	UDP	Alternate signaling port	Use when a firewall’s SIP ALG cannot be disabled
RTP range	UDP	Voice media, PBX-dependent range	Forward to the PBX and accept from any source address
3478	UDP	STUN, for NAT address discovery	Optional, provider-dependent
22 / 443	TCP	PBX management access	Never internet-facing, restrict to trusted admin addresses

What Do Ports 5060, 5061, and the RTP Port Range Do?

Port 5060 carries the signaling that sets up, modifies, and tears down a call. Registration happens there, authentication challenges are answered there, and both ends agree on what media will flow and where. Port 5061 does the same inside a TLS session, making it preferable wherever call metadata matters.

The RTP port range carries the audio, and the PBX sets it rather than the provider. Platforms default to different ranges, so read the documentation rather than assuming. The critical detail is directional: the firewall must forward inbound media to the PBX private address and accept it regardless of source.

Why Does IP Allowlisting Beat Opening SIP Ports to the Internet?

Automated scanners continuously sweep port 5060, and an exposed SIP service will be probed within hours of going live. Restricting signaling to your provider’s published gateway addresses removes nearly all of that noise, since anything from another source is dropped before reaching the PBX. It is the most valuable single change on this list, and it costs nothing.

Media is the exception that trips people up. Audio often flows directly between endpoints rather than through the provider’s gateways, so RTP arrives from an address the firewall has never seen. Apply the same source restriction you used for signaling, and the firewall drops legitimate audio, producing the one-way calls your customer reports. Your PBX only accepts media on a port that an authenticated call has already opened, so leaving the RTP range open to any source is a controlled decision rather than a gap. Lock down the signaling and let the media through.

What Is SIP ALG, and Why Does It Break Calls?

SIP Application Layer Gateway is a firewall feature that inspects SIP packets and rewrites the addresses inside them, attempting to help devices behind NAT communicate correctly. It ships enabled by default on many commercial routers. In theory, it solves a real problem. In practice, implementation quality varies so widely that it causes far more failures than it prevents.

The mechanics matter for diagnosis. When a device behind NAT sends a SIP message, the private address inside the message body is meaningless externally. SIP ALG substitutes the public address so that return traffic knows where to go, then reverses the translation coming back. That requires the firewall to track which internal address and port each session belongs to. Many implementations fail to retain those records, rewrite headers inconsistently, or mangle ports outright. Signaling and media diverge, and the call fails in ways that look random.

Depending on the vendor, the setting appears as SIP ALG, SIP Transformations, SIP inspection, or a VoIP profile. Whatever it’s called, disable it. If the interface offers no way to turn it off, move signaling to the alternate port, since many ALG implementations inspect only 5060.

How Do You Explain SIP ALG to a Customer Without the Jargon?

Tell them the firewall is trying to be helpful by editing the phone system’s messages as they pass through and that it’s not very good at editing. Every time it rewrites a message incorrectly, part of the call gets lost.

That framing gives a reason rather than an instruction. IT contacts push back on “disable this security feature” and accept “this was designed for a different era of phone systems and now interferes with yours.”

Which SIP Trunk Firewall Settings Cause One-Way Audio and Dropped Calls?

Most audio complaints resolve to a small number of configuration errors, and knowing the symptom-to-cause mapping shortens an otherwise long diagnostic session. These are the SIP trunk firewall settings worth checking first, ordered by how often they are the culprit:

• SIP ALG left enabled. One-way audio, calls that connect then drop at a fixed interval, or inbound failures while outbound succeeds.
• RTP restricted by source address. Consistent one-way audio where the customer can be heard but cannot hear.
• RTP range not forwarded to the PBX. Calls connect with no audio in either direction.
• Aggressive UDP session timeouts. Registration drops periodically and inbound calls fail until the PBX re-registers. Extend the timeout beyond the registration interval.
• Signaling and media handled by different NAT rules. Intermittent failures that correlate with call volume rather than any single extension.
• Deep packet inspection still active. Registration succeeds but authentication headers are stripped, producing repeated authorization failures.

Work that list top to bottom before packet capturing. It resolves most cases in under 15 minutes.

How Do TLS and SRTP Fit Into SIP Trunk Security Best Practices?

TLS and SRTP address a different threat than firewall rules. Access control decides who can reach the system. Encryption decides what an observer learns from traffic already in transit. Transport Layer Security protects signaling, concealing dialed numbers, caller identity, and credentials. Secure Real-time Transport Protocol encrypts the audio itself.

They work as a pair. TLS without SRTP protects call setup while the conversation travels in the clear. SRTP without TLS encrypts audio while exposing metadata about who called whom and when, often the more useful intelligence for social engineering. Understanding what secure SIP trunking means shapes which platforms suit regulated customers.

What Should You Tell Customers About Encrypted Calling?

Keep it concrete. Encryption means that if someone captures traffic between their office and the carrier, they get unusable noise instead of a recording. For a law firm, medical practice, or financial advisor, that is a compliance requirement rather than a preference.

Pair encryption with caller identity. The FCC’s caller ID authentication requirements govern how providers digitally sign calls so recipients can trust the displayed number. Unsigned calls get labeled as spam and go unanswered, a revenue problem that customers feel immediately. How a platform handles signing is one of the questions to ask any provider before committing your customer base.

How Do You Handle Toll Fraud Prevention Across Multiple Customer Accounts?

Toll fraud is the risk that scales worst as your portfolio grows. A single compromised PBX can generate a very large bill over a weekend, and the account holder is generally liable. Analysts tracking SIP trunking market growth name rising fraud risk as a factor tempering adoption even as the market expands at a 16.38% compound annual rate through 2031. Attackers follow adoption.

The dealer problem differs from the end-user problem. An IT director secures one system. You are securing systems you didn’t design, with varying firmware and competence on the customer side. Toll fraud prevention has to live in your process, which separates SIP trunk security best practices at portfolio scale from single-site advice.

Which Controls Belong on Every Account by Default?

Block long-distance and premium-rate dialing at provisioning and unblock only on written request. Most customers never need either, and the ones who do will tell you. Apply a concurrent call ceiling slightly above the customer’s realistic peak, since fraud traffic spikes far past normal usage and a ceiling automatically caps damage.

Require unique, complex credentials on every extension and never reuse a password pattern across accounts. Disable unused features that expose dial tone, including direct inward system access and remote voicemail. If someone needs remote access, deliver it over a VPN rather than by opening a port.

What Should You Review Every Week?

Watch for the patterns that precede a large bill. Calls placed outside business hours to destinations the customer has no reason to dial are the clearest early signal. Spikes in concurrent call volume, repeated registration failures from unfamiliar addresses, and unexplained call forwarding changes all warrant a same-day look.

Set billing alerts against each account’s normal spend rather than a flat number across your book, since a 20-seat office and a 200-seat call center have different baselines. Detection speed determines whether an incident costs hundreds or tens of thousands.

What Does a Dealer Troubleshooting Workflow Look Like?

A consistent sequence saves time and makes escalations credible. When a customer reports an audio or connectivity problem, work through these steps in order:

1. Establish scope. One extension, one site, or every account on that platform? A single extension is almost never a trunk problem.
2. Check registration. If the PBX is not registered, the issue is signaling, so move to firewall rules rather than media configuration.
3. Identify the audio direction. No audio either way points to media forwarding. One direction points to source restriction or SIP ALG.
4. Confirm SIP ALG state. Verify it in the firewall rather than trusting an old ticket note because settings get restored during firmware updates.
5. Verify the RTP port range matches what the PBX uses, then confirm it is forwarded and unrestricted by source.
6. Test from outside the network. Registering a softphone on a different connection isolates the customer network as the variable.

Document the resolution against the account. Applying SIP trunk security best practices consistently means the second visit to that network starts from notes rather than from scratch.

How Does VoIP Reseller Security Become a Competitive Advantage?

Security expertise is one of the few genuine differentiators in voice reselling, since price competition compresses margin and feature parity is nearly universal. Customers can’t evaluate your network engineering, but they can tell the difference between a partner who hands them a configuration checklist and one who appears only after the problem starts. VoIP reseller security becomes a sales asset when it’s visible.

It also protects your economics. Every avoided fraud incident and every customer who does not churn after a bad cutover shows up in retained recurring revenue. The guide to reselling SIP trunks covers margin structure, and support cost most often separates a profitable book from a break-even one. Partnering on carrier-grade SIP trunking infrastructure means the network layer is handled, letting you focus at the customer edge.

Frequently Asked Questions

Should I change the SIP port from 5060 to something non-standard? Only when you cannot disable SIP ALG. An alternate signaling port sidesteps ALG implementations that inspect only 5060, but it’s not a security control by itself. Restricting the port to your provider’s gateway addresses accomplishes far more.

Why does my customer have one-way audio only on inbound calls? Almost always SIP ALG or an RTP source restriction. Inbound calls fail more often because the firewall has no prior outbound session to associate the media with. Disable SIP ALG first, then confirm the RTP port range accepts traffic from any address.

Do I need SRTP if the customer is already behind a firewall? Yes, if the call content is sensitive. A firewall controls network access but does nothing to protect traffic once it leaves the premises. Regulated industries generally treat encryption as a requirement rather than an enhancement.

How quickly can toll fraud generate a significant bill? Compromised systems commonly run overnight or across a weekend, when nobody is watching. That is why automated call ceilings and billing alerts matter more than manual review.

Is IP authentication more secure than username and password registration? IP authentication is generally preferable when the customer has a static public address, since no credentials cross the network. Registration-based authentication is the practical choice on dynamic connections and should be paired with TLS so credentials are not exposed in transit.

Building a Secure Foundation for Every Customer You Onboard

The dealers who scale turn security configuration into a template instead of solving it fresh on every install. Restrict signaling, leave media open, disable SIP ALG, standardize fraud controls at provisioning, and review call patterns on a schedule. All of it compounds as your account base grows.

What makes it sustainable is a platform handling provisioning, billing, and network reliability so that your attention stays where it earns customers. SIPTRUNK gives dealers that foundation through a reseller platform built for partners who want recurring revenue without operating a carrier. Explore the SIP trunk reseller program to see how the model works, then get started as a dealer when you are ready to bring secure voice service to your customers.