Is STUN-based NAT traversal usable for explosion-proof telephones?

NAT looks harmless until the first field test. Calls register, then audio goes one-way. Operators blame the phone, but the network path is the real cause.

STUN can help SIP explosion-proof telephones stay reachable behind many NATs, but it is not a complete fix for symmetric NAT or strict firewalls. For high-availability sites, an SBC or relay design is usually safer.

How NAT traversal should be treated in hazardous-area voice projects

What STUN can do for an Ex SIP phone

STUN ¹ is a tool protocol. It lets an endpoint learn the public address and port the NAT assigned, and it can also be used as a keep-alive to keep that mapping open. This is useful when the explosion-proof telephone sits behind a router at a remote tank farm, or behind a firewall in a smaller site office.

In simple NAT cases, STUN helps with two goals:

• The phone can discover its mapped address and report usable information to the SIP core.

• The phone can send periodic traffic so the NAT binding does not time out.

This can reduce inbound call failures after idle time. It also reduces “registered but unreachable” states.

What STUN does not guarantee

STUN is not a relay. When direct media paths fail, STUN alone cannot force a working path. TURN ² is the protocol designed for relaying media when direct communication is not possible. ICE ³ is the full method that tries direct candidates first, then falls back to TURN when needed.

So STUN is usable, but it must be placed inside a broader design that fits the site’s NAT type and availability needs.

A simple selection view

| Site reality | STUN-only result | Safer design choice |

|—|—|—|

| Simple NAT, stable firewall | Often works | STUN + keepalive |

| Symmetric NAT, strict firewall | Often breaks media | SBC ⁴ or TURN/ICE |

| Safety-critical phones | Risky as the only control | SBC + redundancy |

| Multi-site WAN with NAT layers | Unpredictable | SBC + controlled routing |

If the site classifies the phone as a safety communication device, I treat NAT traversal like a reliability topic, not a feature checkbox.

A good plan starts by choosing which NAT traversal methods the endpoint and the voice core will support.

Are STUN, TURN, and ICE all available options?

NAT traversal options are often listed in marketing sheets. Then the installed firmware has only one toggle and no real control.

STUN is common on SIP endpoints. TURN and full ICE are less common on classic SIP phones and are more typical in WebRTC stacks. If a vendor claims TURN/ICE, confirm it with packet captures and a clear test plan.

Why availability differs across endpoint types

Many explosion-proof SIP telephones use embedded SIP stacks that focus on enterprise SIP features. STUN is a lightweight add-on. TURN and ICE add more moving parts:

• candidate gathering and checks (ICE)

• relay allocations and permissions (TURN)

• more timers, more state, and more troubleshooting work

So it is normal to see:

• STUN: available

• ICE: sometimes “ICE-lite” or not present

• TURN: often absent on SIP phones, present in soft clients, present in WebRTC ⁵

This is not a flaw. It is just product scope.

What to request in a spec

When a site asks “support STUN/TURN/ICE,” I rewrite it into testable lines:

• “Supports STUN for NAT mapping discovery and keepalive.”

• “Supports ICE (full or lite) with defined candidate types.”

• “Supports TURN relay for symmetric NAT and blocked UDP cases.”

• “Supports SIP Outbound keepalive methods (CRLF or STUN keepalive) if the core uses Outbound.”

If a vendor cannot answer these in writing, the project should assume STUN-only and design the network around it.

What to check in real packets

A claim is only real if the traffic proves it:

• STUN Binding Requests appear to the STUN server.

• ICE checks show STUN messages with ICE attributes and candidate pairs.

• TURN allocations show Allocate requests and relay addresses.

A procurement checklist table

| Feature claim | Evidence you should ask for | Fast way to verify |

|—|—|—|

| STUN | config page + captures | Wireshark: STUN Binding |

| ICE | detailed feature note | Wireshark: ICE checks |

| TURN | relay support note | Wireshark: TURN Allocate |

| Outbound keepalive | timer controls | observe CRLF or STUN keepalives |

If TURN/ICE is not available, the design still can be reliable. It just needs SBC or controlled routing. That matters most in symmetric NAT environments.

Can symmetric NATs be handled without one-way audio?

One-way audio is the classic “it rings, but nobody hears.” Symmetric NAT makes this common, even when SIP registration looks fine.

Symmetric NAT is hard for direct RTP. STUN alone often fails. Reliable avoidance usually needs a media relay (TURN or SBC) or a network design that avoids NAT between the phone and the voice core.

Why symmetric NAT breaks direct media

With symmetric NAT ⁶, the mapped port can depend on the destination. The phone may learn one mapping through STUN, but media to the SIP peer may use a different mapping. That mismatch causes RTP to land at the wrong place. The call connects, but audio fails.

SIP signaling has its own NAT issues too. The rport mechanism helps servers send SIP responses back to the actual source address and port. That improves SIP reachability, but it does not guarantee media reachability.

What works in real industrial deployments

A practical shortlist that reduces one-way audio:

• Place an SBC or edge proxy near the SIP core and force media anchoring.

• Use TURN or ICE with TURN relay as a fallback when direct fails.

• Avoid NAT for the voice VLAN. Use routed private networks with clear ACLs instead.

• If NAT cannot be avoided, use SIP over TCP/TLS to reduce random UDP pinhole behavior, and use RTP relay at the edge.

In hazardous-area voice, the “simplest” fix is often network design, not endpoint features. A small rugged cabinet with fiber uplink and a local SBC/gateway can remove the long NAT path.

What to test so you do not guess

A FAT should include a symmetric NAT simulator or a real carrier-grade NAT path:

• Place inbound calls after idle time.

• Place outbound calls and validate two-way audio.

• Force NAT binding timeout and confirm recovery.

• Verify the media path is anchored when needed.

A design decision table

| Constraint | Endpoint-only approach | System approach that works better |

|—|—|—|

| Symmetric NAT | STUN may fail | SBC/TURN relay |

| Remote sites | frequent idle drop | keepalive + anchored media |

| Strict firewall | blocked UDP | TCP/TLS + relay |

| Safety call points | unacceptable outage | avoid NAT or enforce SBC |

After media reliability, the next success factor is keepalive timing. Even a good NAT traversal method fails if bindings are not refreshed.

Are keepalive intervals and binding refresh adjustable?

Many “registered” phones go unreachable after 5–15 minutes. That is not a SIP issue. It is a NAT timer issue.

Keepalive and binding refresh are usually adjustable, but the method varies: CRLF keepalive and STUN keepalive are defined in SIP Outbound, and SIP can also negotiate keepalive willingness using the “keep” Via parameter.

The keepalive methods you will see

In real deployments, keepalive shows up in a few forms:

• CRLF keepalive on TCP/TLS flows as described in SIP Outbound ⁷.

• STUN keepalive as another Outbound method to keep NAT bindings alive.

• SIP OPTIONS keepalive. This is common in practice, even if it is not the Outbound keepalive method.

• Small UDP keepalive packets for NAT pinholes.

SIP also has a standard way to indicate support for keepalives using the “keep” Via parameter, so adjacent SIP entities can negotiate keepalive usage even when full Outbound is not used.

What “adjustable” should mean in a spec

I avoid vague language like “supports NAT keepalive.” I ask for:

• interval range (minimum and maximum)

• method selection (OPTIONS vs CRLF vs STUN keepalive)

• failure detection behavior (how many missed keepalives trigger failover)

• interaction with registration expiry and retry timers

A common site-friendly approach is shorter keepalives on remote NAT links and longer keepalives on stable LAN.

A practical interval table

| Transport | Typical keepalive method | Typical interval goal |

|—|—|—|

| UDP | UDP keepalive or OPTIONS | often 15–30s when NAT is strict |

| TCP | CRLF keepalive | often 30–60s |

| TLS | CRLF keepalive | often 30–60s |

| SBC-managed | SBC-driven keepalive | endpoint interval can be higher |

The exact values should match firewall idle timers and carrier policies.

How to verify in FAT

• Capture traffic for 30–60 minutes.

• Confirm keepalives occur at the configured rate.

• Confirm inbound calls still arrive after idle periods.

• Confirm the phone re-registers cleanly after a link flap.

Keepalive keeps reachability. It does not fix SIP ALG problems though. ALG can still rewrite messages and break NAT logic.

Does SIP ALG detection and bypass work reliably?

SIP ALG causes “random VoIP.” It looks like a phone bug, but it is the router rewriting SIP in a half-correct way.

SIP ALG often breaks SIP and RTP handling and can cause one-way audio or failed inbound calls. Many deployments solve it by disabling ALG, or by bypassing it using SIP over TCP/TLS and anchored media. True “ALG detection” inside endpoints is not always reliable, so field validation matters.

Why SIP ALG is a problem in real networks

SIP ALG ⁸ tries to help by rewriting SIP headers and SDP. In practice it often:

• rewrites addresses in ways the SIP server does not expect

• fails to open correct RTP pinholes

• breaks NAT detection logic, so the server stops sending keepalives

This can lead to one-way audio and failed inbound calls.

What an endpoint can do, and what it cannot

Some phones show “NAT detected” status. Some can use STUN to learn external mapping. That helps, but it does not reliably detect every ALG. An ALG can still rewrite packets after the phone measures mapping.

So I treat “ALG detection” as a troubleshooting hint only. I do not treat it as a safety control.

Bypass methods that work more often

• Disable SIP ALG in the router/firewall when possible.

• Use SIP over TLS or TCP. Many ALGs only target UDP, so TCP/TLS can avoid rewriting.

• Use an SBC and anchor media, so RTP always flows to a known edge.

• Use rport on SIP signaling so responses come back to the source port.

A fast symptom-to-fix table

| Symptom | Likely ALG behavior | Fix that works most often |

|—|—|—|

| One-way audio | SDP rewritten wrong | disable ALG, anchor RTP |

| Inbound calls fail after idle | keepalive logic broken | disable ALG, enable keepalive |

| Random re-register | SIP responses misrouted | rport + TCP/TLS |

| Calls drop mid-call | firewall pinholes wrong | SBC + controlled NAT policy |

How to prove “reliable” in FAT

• Run calls through the same router model used on site.

• Run idle tests (no calls) for at least one hour.

• Place inbound calls after idle.

• Introduce packet loss and confirm the phone stays registered and reachable.

If the project cannot control the edge router, it should not rely on ALG behavior. It should use SBC and clear network policy.

Conclusion

STUN is usable for many Ex SIP phones, but it is not a full answer for symmetric NAT or SIP ALG. For safety-critical sites, SBC or relay designs plus tested keepalive settings are the safer path.

Footnotes