Current Location ：
RTP Port Ranges and Firewall Planning for Voice
Firewall rules for voice are usually written once, during a deployment, by someone who has a port list in front of them and a schedule behind them. They then remain untouched while the call volume grows, the platform is upgraded, and a new carrier is added. The result is a rule set that mostly works, fails occasionally under load, and cannot be explained by anyone currently on the team. This article covers how media ports are actually allocated, how to size a range against real concurrency, and how to keep the port plan truthful over time.
Signalling and Media Are Different Problems
Signalling typically uses a single known port and is easy to allow. Media is allocated dynamically: for each call, each direction, the platform picks a port from a configured range. The range must therefore be large enough for the number of simultaneous media streams, and every device on the path must agree on which ports are permitted. A rule that allows the signalling port but blocks most of the media range produces calls that connect and then fall silent, which is a far more confusing symptom than a call that simply fails.
| Element | What it needs | Common planning error |
|---|---|---|
| SIP signalling | One or two known ports, UDP or TCP/TLS | Allowing UDP only when TLS is later enabled |
| RTP media | A contiguous UDP range sized for concurrency | Range sized for extensions, not for simultaneous calls |
| Each call leg | Two streams, one per direction, one port each | Forgetting that a bridged call uses two legs |
| Recording or transcoding | Additional media handling on the platform | Assuming recording reuses the same ports |
| Remote endpoints | Reachable media path or relay at the edge | Rules written for internal addresses only |
Sizing the Range
A useful rule of thumb is two ports per concurrent call leg, then a margin. A system handling 100 simultaneous bridged calls has 200 streams, and if each call crosses between an internal and an external leg the platform may allocate ports on both sides. Sizing for the number of extensions is the classic mistake: an office with 300 extensions and 30 trunk channels will never need 600 media ports at once, while the same office during an all-hands broadcast might need far more than the trunk count suggests.
- Size the media range against peak simultaneous streams, not against extension count
- Keep the range contiguous; scattered ports are difficult to audit and easy to misconfigure
- Reserve headroom for recording, conferencing, and paging, which add streams
- Record the range in the network documentation and in the carrier handover pack
- Re-check the range after any platform upgrade, since defaults can change
Rules That Survive Change
A firewall rule set for voice should be readable by someone who did not write it. That means naming rules by purpose, referencing the port plan rather than individual numbers scattered across a policy, and stating the direction of each flow. Where a session border controller owns the media path, the internal rule set can be narrow and the edge rule set explicit, which is easier to review than a policy that permits a wide range to many internal hosts.
Auditing Without an Outage
The safe way to verify a rule set is to log denies during a busy period and read them, rather than to tighten rules and wait for complaints. Most firewalls will show denied traffic with source, destination, and port, which is exactly the evidence needed to confirm the range is correct and to spot traffic you did not know existed.
Redstone Approach
Redstone provides port and address requirements in writing as part of deployment, covering signalling, media, and any additional streams created by recording or conferencing. We agree the plan with the team that owns the firewall before cutover, and we test media in both directions separately so that a partially permitted range is caught during commissioning rather than during a Monday morning call.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
