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

[alexandre.ferrieux at orange-ftgroup.com]

On 11/02/2010 08:47, Luca Abeni wrote:
> 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.


Indeed when you talk to a vanilla RTSP server you must give it your outside, NATted ports, so either you use an external 
STUN server, or you have a more cooperative NAT that answers your UPnp/IGD queries and tells you the outside ports directly.

However, I daily face other situations where I control the server (typically ffmpeg too ;-), and this punching method is 
great, much simpler than STUN or IGD. Today I do this by doing the UDP I/O outside ffmpeg, but having it inside (for 
both roles) would be a plus.

-Alex


*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************