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

[John Wimer]

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.
>> The simple act of sending a UDP packet through the NAT usually creates a
>> port forward to the client. It's a simple system, frequently works, and
>> has no major drawbacks.
>>      
> It would work if you could convince the RTSP server to send RTP/RTCP packets
> to where the packets came from, instead of to the client_port pair in the
> Transport field. But there are no standard transports with such semantics. And
> my suggestion to this end were more or less ignored on the IETF MMUSIC working
> group a few years back.
>
> In other words, this technique works if you have a stateful firewall but no
> NAT. It also work for a few totally idiotic NATs that preserve port numbers.
>
>    
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?