[vlc-devel] Bounty tasks details request

[Gilles Chanteperdrix]

O Sat, Dec 21, 2013 at 04:10:43PM +0200, Andrey Utkin wrote:
> 2013/12/21 Gilles Chanteperdrix <gilles.chanteperdrix at xenomai.org>:
> > 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
> 
> May be packets to STUN server.
> I wonder how could you capture them and change your server behaviour
> based on them, as your media server mustn't be the party of STUN
> communication session.

No, this has nothing to do with STUN. Live555, and vlc because it uses
live555 sends packets from the sockets it uses for receiving RTP to
the port the server uses to send the RTP. It sends these packets "the
wrong way", because this causes the router to open the port which will
allow the client to receive the RTP stream sent by the server. This is
how classical UDP NAT works, which allows for instance your box behind
a NAT to issue DNS requests. So, on the server, I simply have to listen
on the sockets I am going to use to send the RTP stream, and note the 
IP address and source ports of the packets I receive, in order to use
this source port instead of the port negotiated with RTSP. 

> 
> > I also spent some time on streaming from a machine behind NAT
> 
> This is important issue for VoIP, but not that real issue for media
> streaming server IMO. But still, TCP interleaving of RTP would work
> well if RTSP server is behind NAT and only a single port (of RTSP
> listening, like 554) is forwarded on external router.
> 
> Again - the real life scenario seems to me the one where streaming
> server is public host, and clients may be behind NAT. Streaming server
> cannot sort out the problems of bad NAT (it can only send packets to
> IP and port given by client), that is possible to sort out on client
> side only, and depends on NAT type after all.

I believe the server can sort out the problem, the way I indicated,
if you have a box behind a "broken" NAT, please try:

rtsp://xenomai.org:8554/video-tests/hd-fast.mp4

-- 
					    Gilles.