[vlc-devel] Bounty tasks details request

[Gilles Chanteperdrix]

Andrey Utkin wrote:
> IIRC, to fix UDP NAT traversal, the behind-NAT agent must "work on
> it", and server cannot do anything reasonable to "fix" the situation.

I do not know how much this is relevant, but I have worked on trying
to get a live555 server with a public IP address to work well with all
clients behind NAT. Amittedly, I am new to the business of video streaming,
so my approach may be naive, but what I have noticed is that the client
behind NAT sends UDP packets before starting playback on the server in
order to "open" the NAT, so, I have modified live555 to use the port
number in these packets instead of the client port number negotiated in
the RTSP. It "fixes" NAT traversal for routers without conntrack_rtsp,
but will probably never been merged as is in live555, because it allows
an attacker who sends a packet on the right port at the right time to
hijack an RTP stream. This is not a problem in my case, since my aim
is to stream public videos from public server (so there is no reason for
an attacker to try and hijack an RTP stream in the first place, since he
can just as well subscribe to the stream), but this would be a problem
for IP camera feeds. That said, the approach could be improved by requiring
the client to write his RTSP session ID into the packet, instead of sending
the fixed identifier it sends now (0xFEEDFACE). In that case, an attacker
would not only have to guess a port number, but also a correct session ID
to be able to hijack an RTP stream.

I also spent some time on streaming from a machine behind NAT, to another
machine behind NAT by using a relay server with a public IP address. The
two machines would rendez-vous on an UDP port: the sending machine would
send its RTP/UDP stream to a pre-defined UDP port on the public server, and
the client machine would open rtsp://server/port-number to cause the server
to broadcast the stream. The server code is very short and I can provide
it if anyone is interested, but it really is just a proof of concept.

Finally, while looking at these NAT issues, I also found that there is an
RFC for a protocol called ICE which addresses the issue of NAT traversal:
http://tools.ietf.org/html/rfc5245

Regards.

-- 
                    Gilles.