[FFmpeg-devel] [PATCH] Send NAT punching packets when starting to read an RTP/UDP stream

[Luca Abeni]

Hi Martin,

Martin Storsj? wrote:
> Hi,
> 
> The current code for receiving RTP/UDP streams doesn't work too well if 
> the receiver is behind NAT (unless the NAT inspects the RTSP setup 
> conversation and sets up forwarding for those ports).
> 
> Other players (such as RealPlayer on Symbian S60) handles this by sending 
> one dummy packet on each UDP port when starting the stream, in order to 
> set up proper forwarding rules in the NAT.

Yes, this is an interesting feature, but... How does it work?

I mean: assume you have a client C with a private IP, which is
behind a NAT and wants to play a stream from a server S (having
a public IP, obviously).

C contacts the server via RTSP and negotiates two ports for the
audio and the video streams. These are "private" ports (meaning,
they are opened on the private interface of C).
Then C sends some UDP packets to S, from those ports (to which
destination ports? The same as the RTP ports on C?). The packets
pass through the NAT, and arrive to S from a different source
IP (the NAT public IP) and a different source port (the port
on which the NAT machine remaps the "private" source port used
by C). So, the forwarding rules in the NAT are properly set up,
but now if S works according to the RTSP standard (sending
packets to the UDP ports negotiated through RTSP) these packets
will hardly arrive to C...

I _suspect_ that this feature would be pretty useless without
using some "STUN like" protocol, no?

So, I assume this works only if the server does something smart,
which does not seem to be described in the RTSP standard?
Is this correct? If yes, maybe we can identify the servers which
support this feature (we already try to identify MS RTSP servers
and Real servers) and send these packets only in this case.

> The dummy packets sent from RealPlayer on Symbian are empty RTCP receiver 
> reports (sent on both the RTP and RTCP ports)

I suspect sending an RTCP packet on an RTP port is highly
non-standard ;-)


> but due to the nature of 
> the RTP protocol in libavformat, we can't force an RTCP packet on the RTP 
> port, so instead I chose to send a minimal RTP packet with no payload 
> content.

This would be more standard, I guess... did you check if this works?
Which kind of RTSP server did you use?


			Thanks,
				Luca