[vlc-devel] Issue 66 -- NAT traversal of RTSP

[John Wimer]

Hello,

I saw this old ticket [http://trac.videolan.org/vlc/ticket/66] about NAT 
traversal for RTSP and wondered if it can be re-visited. I agree with 
the comments that using STUN is impractical because it requires control 
of the RTSP server in order to work with all NATs. If the NAT is 
"well-behaving", there shouldn't be need for any STUN, because the NAT 
can open the ports by inspecting the RTSP SETUP messages.

Back in the real world, NATs usually don't inspect the RTSP traffic. One 
technique used to convince a NAT to open a port is to send so-called 
punch packets. These truncated packets come from the listening rtp and 
rtcp ports and are directed to the server's sending rtp and rtcp ports. 
All RTSP servers that I know of simply discard the packets as corrupt. 
The simple act of sending a UDP packet through the NAT usually creates a 
port forward to the client. It's a simple system, frequently works, and 
has no major drawbacks.

FFmpeg uses this technique (see rtp_send_punch_packets() in 
libavformat/rtpdec.c) and I think it could be added to VLC easily. My 
hasty read through the VLC code leads me to think these packets could be 
sent from the beginning of rtp_thread() in modules/access/rtp/input.c. 
Should I work up a patch, or am I missing something?

Best regards,

John Wimer