[vlc-devel] Bounty tasks details request

Rémi Denis-Courmont remi at remlab.net
Sun Dec 22 19:55:57 CET 2013


Le samedi 21 décembre 2013, 14:42:16 Gilles Chanteperdrix a écrit :
> 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,
(...)

Sorry but this is wrong. There is no requirement for the client to send a 
packet on the RTP port. Some clients might do it for firewall friendliness, but 
the server cannot rely on that - and it cannot possibly work if multiple SETUP 
requests are pipelined or there are multiple clients behind the same IP.

This is a Bad Idea in any case. If you care about NAT traversal, use some 
HTTP-based protocol. If you really must use RTSP, use interleaving.

> 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

Yes but no. ICE is not specified for RTSP 1.0. It might be specified for RTSP 
2.0 but the last time I checked ,the draft had already turned into a gas 
factory (horribly and needlessly complicated to implement). And I am not sure 
RTSP clients will ever support 2.0.


That leaves three possibilities for NAT traversal of RTSP. RTSP ALG and RTSP 
proxy do not require change to the (VLC) server and thus do not qualify as 
bounties. Interleaving would require major changes to the VLC HTTPd core; I 
think it is unreasonable to implement it until after the HTTPd core becomes 
(multi)threaded.

So I must repeat that I find this bounty non-sensical.

-- 
Rémi Denis-Courmont
http://www.remlab.net/




More information about the vlc-devel mailing list