[vlc-devel] Issue 66 -- NAT traversal of RTSP

Rémi Denis-Courmont remi at remlab.net
Fri Nov 19 21:25:59 CET 2010


Le jeudi 18 novembre 2010 11:10:58 John Wimer, vous avez écrit :
> On 11/17/2010 06:31 PM, Rémi Denis-Courmont wrote:
> > Le mercredi 17 novembre 2010 11:50:54 John Wimer, vous avez écrit :
> >> Back in the real world, NATs usually don't inspect the RTSP traffic. One
> >> technique used to convince a NAT to open a port is to send so-called
> >> punch packets. These truncated packets come from the listening rtp and
> >> rtcp ports and are directed to the server's sending rtp and rtcp ports.
> > 
> > That will create a mapping on the NAT between the internal client ports
> > and some unknown ports on the Internet side of the NAT.
> 
> It's possible for the internet side ports to have the same number as on
> the client. I think that is the most common for home routers.

I don't think so. This scheme fails miserably with more than one host behind 
the NAT. Yet the whole point of NATs are to hide multiple hosts behind one  IP 
addresses. Yes, they are broken NAT implementations out there. But I think we 
should definitely not use them as the benchmark.

Furthermore, VLC lets the OS select the source ports for receiving RTP. That's 
most often going to be 1024 or 32768 plus a small offset, such that the risk 
of collision with another host behind the same NAT are actually quite high.

Anyway...

> Yes, it's a pity that it's not more robust. I know that sending punch
> packets will only help in a limited number of cases, but I think sending
> them is better than not sending them. Would a patch for this be accepted?

I am afraid this is a moot issue because the concerned code path is not part 
of VLC, but rather the live555 library.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis



More information about the vlc-devel mailing list