Why is my audio one-way after registration works?

Registration is signalling only. If an endpoint writes its private address into the SDP c= line, the far end sends RTP to an unroutable address. Read the SDP from both sides to confirm.

Should I turn on the SIP ALG?

Often not. ALGs are meant to rewrite private addresses but many implementations mangle the message. If registration or media is flaky behind the router, disable the ALG and use keep-alive or STUN instead.

What does STUN actually do?

STUN (commonly UDP 3478) lets the endpoint discover its public IP and NAT type so it can place the correct public address in its SDP. It does not relay media.

When is TURN required?

When there is no direct path, such as two endpoints behind symmetric NAT. TURN relays all RTP through a server, which guarantees connectivity at the cost of relay bandwidth and latency.

Does enabling a media relay cost server bandwidth?

Yes. By default RTP is end-to-end and the server handles only signalling. A relay such as rtpengine terminates media on both sides, so every call's audio flows through the server and consumes its bandwidth.

Does FlySip remove echo on these calls?

No. Echo cancellation is the job of the sister product FlyAec, and background noise reduction is FlyDenoise. The SIP server and relay handle routing and transport, not acoustic processing.

ENGINEERING · NETWORK · 10 min read

SIP NAT Traversal and RTP Relay Explained

How SIP behaves behind NAT, why media goes one-way, and the trade-off of enabling a server-side RTP relay.

2026-11-06 · FlySip engineering · All guides

Place a SIP terminal behind a home or site router and registration may succeed while the call audio does not. The signalling is small and server-facing; the media is peer-to-peer and suddenly has to cross a NAT boundary the phone was never told about.

SIP separates signalling (REGISTER, INVITE) from media (RTP). The server can see and answer the signalling, but the RTP streams are negotiated in the SDP body with IP addresses the endpoints believe are their own. When those addresses are private, the far end tries to send audio to a non-routable address.

Why one-way audio starts with SDP

The INVITE and its 200 OK carry an SDP body that announces where each side will receive RTP: connection-address in the c= line and ports in the m= line. If an endpoint behind NAT writes its private address (for example 192.168.x.x or 10.x.x.x) into that SDP, the remote party sends RTP to a private address it cannot route to.

Audio fails in one direction because the path is asymmetric. The internal endpoint can usually send RTP out toward the public address it learned, so the caller hears the callee; but the callee's return packets go to a private address and vanish. This is the classic one-way-audio symptom, and the cause is almost always a private address inside SDP.

SIP ALG, keep-alive and why ALG often hurts

A SIP ALG on the router is meant to fix exactly this: it rewrites the private addresses in the Via, Contact and SDP headers to the public address. In practice many ALG implementations are buggy and corrupt the message, breaking registration or media worse than leaving it alone.

Keep-alive is the lighter fix for UDP. Because UDP has no connection, the NAT binding expires after a short idle period and inbound packets start being dropped. Sending periodic REGISTER or OPTIONS messages (or short RTP comfort packets) keeps the binding open so inbound RTP can return. This is why a call that works for a few seconds then loses audio is often a missing keep-alive.

SIP ALG — intended to rewrite private addresses; often buggy, disable if flaky.
Keep-alive — REGISTER/OPTIONS ping keeps the UDP NAT binding alive.
Symmetric NAT — both sides behind strict NAT need a relay; ALG alone will not help.

STUN and TURN

STUN (commonly on UDP 3478) lets an endpoint discover its public address and the type of NAT it is behind, so it can write the correct public address into its SDP. STUN works when the NAT allows the endpoint to receive responses on the same mapped address it sent from.

TURN is the fallback when direct media is impossible, such as two symmetric NATs. The endpoint sends all RTP through a TURN relay server, which forwards it. TURN guarantees connectivity but every packet now traverses the relay, so the relay incurs bandwidth and latency cost.

When to enable a server-side media relay

By default the SIP server handles signalling only and RTP flows end-to-end between the terminals. That is the cheapest path: the server spends no bandwidth on media. The moment you cannot get media through NAT with STUN or ALG, a media relay becomes the pragmatic choice.

A media relay such as rtpengine sits in the media path and terminates RTP on both sides, rewriting SDP to point at the relay's public address. This solves NAT traversal and also supports topology hiding, where internal addresses never leave the site. The cost is server bandwidth: every call's audio now flows through the server, so capacity depends on the relay host's NIC and link, not just the SIP signalling load.

Approach	What it fixes	Cost
Keep-alive	UDP binding timeout / dropped return RTP	Negligible
STUN	Endpoint learns its public SDP address	Negligible, UDP 3478
TURN	Symmetric NAT, no direct path	Relay bandwidth + latency
Server media relay	NAT traversal + topology hiding	Server bandwidth per call

Bandwidth figures for a relay depend on codec and call volume; size the relay host from the expected concurrent media sessions, not from the SIP signalling count.

Verification order

Confirm the fault before changing topology. Capture the SDP from both sides of the call and read the c= and m= lines: if either shows a private address, that is your one-way-audio source.

Then decide the lightest fix that works: enable keep-alive first, try disabling a broken ALG, then STUN, then TURN or a server relay only when direct media truly cannot succeed.

Capture SDP both ways; read c= and m= for private addresses.
Enable UDP keep-alive on the terminal.
Disable a suspect SIP ALG; try STUN (UDP 3478).
Use TURN or a server media relay only as last resort.

Remember: TLS protects signalling and SRTP protects media. Neither changes the addressing problem that NAT creates — they are separate concerns from traversal.

Frequently asked questions

Why is my audio one-way after registration works?: Registration is signalling only. If an endpoint writes its private address into the SDP c= line, the far end sends RTP to an unroutable address. Read the SDP from both sides to confirm.
Should I turn on the SIP ALG?: Often not. ALGs are meant to rewrite private addresses but many implementations mangle the message. If registration or media is flaky behind the router, disable the ALG and use keep-alive or STUN instead.
What does STUN actually do?: STUN (commonly UDP 3478) lets the endpoint discover its public IP and NAT type so it can place the correct public address in its SDP. It does not relay media.
When is TURN required?: When there is no direct path, such as two endpoints behind symmetric NAT. TURN relays all RTP through a server, which guarantees connectivity at the cost of relay bandwidth and latency.
Does enabling a media relay cost server bandwidth?: Yes. By default RTP is end-to-end and the server handles only signalling. A relay such as rtpengine terminates media on both sides, so every call's audio flows through the server and consumes its bandwidth.
Does FlySip remove echo on these calls?: No. Echo cancellation is the job of the sister product FlyAec, and background noise reduction is FlyDenoise. The SIP server and relay handle routing and transport, not acoustic processing.

One-way audio is only half the story once calls connect. For the records those calls generate, read the CDR guide, and for the underlying signalling faults start at SIP registration troubleshooting. Browse all SIP guides or the FlySip product overview.