The Ultimate Protocol Guide for Long-Distance Video Streaming

Why RTSP TCP and RTMP Are Still Your Best Choices for Cross-City and Cross-State Camera Communication

Technical Brief | WINK Streaming Engineering Team
Last Updated: August 2025
Reading Time: 15 minutes

Executive Summary

When streaming video across large geographic distances—between cities, across states, or even internationally—protocol selection becomes critical. After extensive real-world deployments and thousands of hours of testing, we can definitively state: RTSP over TCP and RTMP remain the most reliable choices for long-distance camera communication.

This document focuses on transport protocols. For codec selection, see our companion brief: Why H.264 Is Almost Always The Answer. Together, these guides provide a complete streaming strategy.

Key Finding: Despite being decades old, RTSP TCP continues to outperform newer protocols in real-world long-distance deployments. RTMP, once considered obsolete after Adobe discontinued Flash Media Server, has experienced a remarkable renaissance and is now our co-recommended protocol for cross-city streaming.

The Four Contenders

RTSP TCP

25+

Years Proven

RTMP

98%

Firewall Success

RTSP UDP

15%

Packet Loss Tolerance

SRT

<5%

Current Adoption

Protocol Deep Dive

RTSP over TCP RECOMMENDED

The Venerable Champion: RTSP TCP might be old, but it's old for a reason—it works. Using TCP's reliable transport, RTSP ensures every packet arrives in order, making it ideal for high-latency, lossy networks typical of long-distance connections.

✓ Advantages

100% packet delivery guarantee
Firewall-friendly (single port 554)
Universal camera support
No special network configuration
Excellent through CGNAT/NAT
Proven over satellite links
Built-in congestion control

✗ Drawbacks

Higher latency than UDP (acceptable for surveillance)
TCP overhead (~5-10%)
Can struggle with extreme jitter
Requires stable connection

Real-World Performance: In our deployments spanning from New York to Los Angeles (2,800 miles), RTSP TCP maintains stable 1080p30 streams with only 2-3 seconds of latency. Compare this to UDP variants that often fail completely due to packet loss.

RTMP RECOMMENDED

The Phoenix Protocol: RTMP was left for dead when Adobe abandoned Flash Media Server. But like a phoenix, it has risen from the ashes. Today, RTMP is experiencing unprecedented adoption, supported by every major streaming platform and CDN.

✓ Advantages

Single TCP port (1935)
Exceptional firewall traversal
Built-in reconnection logic
Multiplexed audio/video/data
CDN-ready without modification
Extensive ecosystem support
Automatic bandwidth adaptation

✗ Drawbacks

Limited to H.264/AAC (actually a benefit - see our H.264 technical brief)
Adobe's abandoned documentation
Some cameras lack native support
Slightly higher CPU usage

Why It Works: RTMP's resurrection is no accident. Its simple, robust design excels at long-distance streaming. The protocol's built-in buffering and reconnection mechanisms make it incredibly resilient to network interruptions common in WAN deployments.

RTSP over UDP NOT RECOMMENDED

The LAN Champion, WAN Disaster: RTSP UDP excels in local networks but fails catastrophically over long distances. Without TCP's reliability, even minimal packet loss creates unwatchable streams.

✓ Advantages

Lowest latency option
Minimal protocol overhead
Good for multicast scenarios
Less CPU usage

✗ Drawbacks

Fails with >0.1% packet loss
Requires multiple ports (nightmare for firewalls)
No congestion control
Often blocked by corporate firewalls
CGNAT/NAT traversal issues
No inherent error recovery

The Numbers Don't Lie: In our cross-state testing, RTSP UDP streams failed 73% of the time due to firewall issues alone. When they did connect, average packet loss of 0.5% made streams unwatchable.

See Also: For a detailed analysis of why H.264 is the optimal codec choice for unreliable networks (which pairs perfectly with reliable transport protocols), read our technical brief: Why H.264 Is Almost Always The Answer. The combination of H.264's resilience and TCP's reliability is unbeatable for long-distance streaming.

SRT (Secure Reliable Transport) PROMISING BUT IMMATURE

The Future That Isn't Here Yet: SRT promises the best of both worlds—UDP's low latency with reliability features. In practice, it's a configuration nightmare with limited support.

✓ Advantages

Modern protocol design
Built-in encryption
Excellent error recovery
Low latency potential
Active development

✗ Drawbacks

Firewall configuration complexity
Limited camera support
Few compatible players
Requires UDP hole punching
Inconsistent implementations
Limited troubleshooting tools
IT departments hate it

Reality Check: While SRT shows promise in controlled environments, real-world deployments face constant firewall battles. IT departments, already wary of opening UDP ports, often refuse SRT deployments entirely.

Network Optimization: The BBR2 Advantage

How WINK Streaming Appliances Maximize Long-Distance Performance

All WINK Streaming appliances utilize BBR2 (Bottleneck Bandwidth and Round-trip propagation time), Google's revolutionary congestion control algorithm. This provides dramatic improvements for long-distance streaming:

Metric	Traditional TCP (CUBIC)	WINK with BBR2	Improvement
Throughput (High Latency)	12 Mbps	47 Mbps	+292%
Recovery Time (Packet Loss)	8.3 seconds	1.2 seconds	-86%
Bandwidth Utilization	45%	91%	+102%
Latency Variance	±340ms	±45ms	-87%

BBR2 Configuration for WINK Appliances


                # Automatically configured on all WINK appliances

                net.core.default_qdisc = fq

                net.ipv4.tcp_congestion_control = bbr2

                net.ipv4.tcp_ecn = 1

                net.ipv4.tcp_ecn_fallback = 1

Real-World Impact: A state DOT streaming traffic cameras from rural areas to their central command center saw stream reliability increase from 67% to 94% after deploying WINK appliances with BBR2.

Firewall Considerations

Protocol	Ports Required	Firewall Complexity	IT Acceptance
RTSP TCP	554/tcp	Simple (single port)	High ✓
RTMP	1935/tcp	Simple (single port)	High ✓
RTSP UDP	554/udp + RTP range	Complex (dynamic ports)	Low ✗
SRT	Custom UDP	Very Complex	Very Low ✗

Firewall Reality: In enterprise environments, getting a single TCP port opened can take weeks. Getting UDP port ranges approved? Good luck. This alone makes RTSP TCP and RTMP the only viable choices for most deployments.

Real-World Deployment Scenarios

Scenario 1: State DOT Traffic Cameras

Challenge: Stream from 500+ cameras across a state to central command
Distance: Up to 400 miles
Network: Mix of fiber, microwave, and cellular
Solution: RTSP TCP with WINK Media Routers using BBR2
Result: 99.3% uptime, 2.1 second average latency
Note: All cameras use H.264 encoding for maximum resilience on cellular connections (see our H.264 technical brief)

Scenario 2: Multi-City Retail Chain

Challenge: Stream security cameras from 200 stores to corporate HQ
Distance: Nationwide (up to 3,000 miles)
Network: Business broadband with CGNAT
Solution: RTMP with fallback to RTSP TCP
Result: 98.7% uptime, seamless firewall traversal

Scenario 3: International Media Company

Challenge: Live broadcast feeds between continents
Distance: 6,000+ miles
Network: Dedicated circuits with satellite backup
Solution: RTMP primary, RTSP TCP backup
Result: Broadcast-quality delivery with automatic failover

WINK Streaming's Official Recommendation

For long-distance camera communication across cities and states, use:

RTSP over TCP

RTMP

Deploy both when possible for maximum reliability and compatibility.

Configuration Best Practices

RTSP TCP Optimization

# Camera Configuration
rtsp_transport=tcp
tcp_timeout=60
keepalive_timeout=60
buffer_size=2048k

# WINK Media Router
reconnect_interval=5
max_reconnect_attempts=unlimited
tcp_nodelay=true
socket_buffer=4096k

RTMP Optimization

# Stream Configuration
buffer_time=8000ms
chunk_size=4096
window_size=5000000
peer_bandwidth=5000000

# WINK Forge Settings
rtmp_buffer=10s
rtmp_live=true
rtmp_tcp_nodelay=on

The Future of Long-Distance Streaming

What's Coming Next?

WebRTC with WHIP/WHEP: Showing promise but requires mature infrastructure. Currently limited by browser constraints and NAT traversal complexity.

QUIC-based Protocols: Google's QUIC may eventually replace TCP for video streaming, offering built-in encryption and better congestion control. Media over QUIC (MoQ) is in early development.

SRT Evolution: If firewall vendors embrace SRT and configuration becomes automated, it could become viable. Don't hold your breath.

Our Prediction: RTSP TCP and RTMP will remain dominant for long-distance streaming through 2030. Their simplicity, reliability, and universal support are unmatched. Sometimes, older really is better.

Testing Your Protocol Choice

Quick Protocol Test

Use these commands to test connectivity before deployment:

# Test RTSP TCP
curl -v telnet://camera-ip:554

# Test RTMP
curl -v telnet://server-ip:1935

# Test SRT (if you must)
nc -u -v server-ip 9000

Performance Metrics to Monitor

Packet Loss: Must be <0.1% for UDP protocols
Jitter: <50ms for stable streams
Round-Trip Time: Factor 3x RTT into buffer calculations
Bandwidth Utilization: Aim for 80% of available bandwidth

Conclusion

After years of real-world deployments and millions of streaming hours, the verdict is clear: RTSP over TCP and RTMP are the optimal choices for long-distance video streaming. They may not be the newest or most exciting protocols, but they consistently deliver where it matters—reliability, compatibility, and ease of deployment.

The WINK Streaming family of appliances, optimized with BBR2 and decades of protocol expertise, ensures maximum performance regardless of distance. Whether you're streaming across town or across continents, RTSP TCP and RTMP—properly configured—will get your video there reliably.

Remember: In long-distance streaming, boring is beautiful. Choose protocols that work, not protocols that promise to work someday. And when it comes to codecs, stick with H.264—as we explain in our companion technical brief, newer isn't always better.

WINK Streaming
wink.co | 1-312-281-5433