If you've ever used a VoIP phone behind a home router — or made a WhatsApp call, a Zoom call, or any modern voice/video call routed through SIP infrastructure — you've benefited from this tiny three-character extension: rport. RFC 3581 is barely seven pages, but it's the patch that made SIP actually work on the real, NAT-ridden Internet.

The problem. SIP (RFC 3261) was designed with a beautiful, symmetric assumption: a client sends a request from some port, and the server sends responses back to the address and port the client advertised in its Via header. That works perfectly when endpoints have public IPs. It collapses the moment you put a NAT in the middle.

Here's the failure mode. A SIP phone behind a home router sits at 192.168.1.50:5060. It sends a REGISTER to a provider's server. The NAT rewrites the source to, say, 203.0.113.7:48291. But the phone wrote its private address into the Via header, and even if the NAT helpfully rewrites the IP, the port in Via still says 5060 — which is not the port the NAT mapped. The server dutifully sends the response to 203.0.113.7:5060, which the NAT drops because there's no mapping for it. Call setup silently fails. Worse, registrations from the same NAT collide because the server can't tell two phones apart.

The fix. Rosenberg and Schulzrinne proposed something almost embarrassingly simple: when a client wants symmetric routing, it adds an empty parameter rport to its Via header:

Via: SIP/2.0/UDP 192.168.1.50:5060;rport;branch=z9hG4bK...

The server, on receipt, observes the actual source IP and port the packet arrived from — the NAT's external mapping — and writes them back into the Via:

Via: SIP/2.0/UDP 192.168.1.50:5060;received=203.0.113.7;rport=48291;branch=z9hG4bK...

The response is then sent back to that observed address and port, which the NAT still has a mapping for. Symmetric routing achieved.

Design decisions worth noting.

• Client opt-in. The presence of bare rport is the signal. Servers MUST NOT do this unless asked, preserving backward compatibility with RFC 3261's strict semantics.
• Reuses received=. RFC 3261 already defined a received parameter for the source IP. RFC 3581 just extends the idea to the port. Minimal surface area.
• Connection reuse. The spec also says the server should send the response over the same socket it received the request on, not open a new one. This is the part that actually keeps the NAT mapping alive — addressing alone isn't enough if you originate a new flow.
• Keepalives are out of scope. NAT bindings expire. rport fixes routing during a transaction but doesn't keep the mapping alive between them — that's why SIP clients also send periodic keepalives (OPTIONS pings, double-CRLF, or STUN).

Why it still matters. Every consumer VoIP service, every softphone, every SIP trunk between an enterprise PBX and a carrier — they all use rport. It's so universally deployed that most SIP stacks turn it on by default; some don't even expose a switch. It's the canonical example of a "small RFC that fixed a huge operational problem" — the same family as RFC 7413 (TCP Fast Open) or RFC 6555 (Happy Eyeballs). Symmetric response routing also foreshadowed the broader pattern that ICE (RFC 8445) later generalized for media: trust what you observe on the wire, not what the peer claims about itself.

Backstory. Jonathan Rosenberg, one of SIP's principal architects, has joked that a substantial fraction of his IETF output has been "papering over the fact that SIP doesn't really work through NATs." RFC 3581 is the smallest and most successful of those papers.