[vlc-devel] [PATCH] live555: fix the subtitles issue

[Gilles Chanteperdrix]

On 12/30/2013 03:08 PM, Rémi Denis-Courmont wrote:
> Le lundi 30 décembre 2013, 14:57:40 Gilles Chanteperdrix a écrit :
>> Do you know how NAT traversal works for any UDP connection, like e.g.
>> DNS requests?
> 
> Yes and that is entirely different from RTP.
> 
>> I am doing the same thing.
> 
> You cannot do the "same thing". DNS is a request/response protocol. The client 
> does not need to know its outer source address and port pair. Futhermore, the 
> NAT flow only lasts a few seconds at most. until one packet is received.
> 
> RTP is completely different.

Well, if the client sends a packet on the server RTP port before the
server starts sending packet from its RTP port to the firewall port
where the original packet seemed to come from, the firewall will "see"
the RTP stream as an answer to this original packet. So, it is the same
thing. At least, for the first RTP packet.

> 
>> It requires a little modification of the client,
> 
> No. Changing the client will not help. Only the NAT and the server knows the 
> outer address and port pair. While you can just tell the server to reuse the 
> same address as that of the TCP connection, you are still left guessing the 
> UDP port number for the SETUP request.
> 
>> which is already implemented in live555 and ffmpeg, because it
>> seems to be required even if the firewall has ALG.
> 
> No. If the firewall has a working RTSP ALG, you don't need to punch holes, by 
> definition.

I do not know if my firewall has RTSP ALG, because unfortunately, it is
closed source. but it allows streaming RTSP over UDP. What it does to
achieve that is that it opens on the firewall the ports that were
negociated in the RTSP negociation and redirects them to the same ports
on my PC. But I can confirm you that it needs the "hole punching" after
having paused a stream. Otherwise it closes the port. I have tripled
check, without punching holes, it does not work, with punching holes, it
works.

> 
>> And a modification of the server to use that supplementary information sent
>> by the client.
> 
> Then it is no longer RTSP but some non-standard and non-interoperable dialect 
> of RTSP. Your "enhanced" client will not work while talking with a plain 
> standard server.

How so? If the standard compliant server simply ignores the packets it
receives on the UDP port it is sending its RTP stream from, everything
will work. Note that as of vlc 2.0, vlc 2.0 is such a "enhanced",
"non-interoperable" client.

> 
>> the server can still obey the standard if it does not receive the
>> information.
> 
> In other words, NAT traversal does not work without cooperation from the 
> server. That's exactly what I said. You are contradicting your own self.
> 

Then we agreed from the beginning, and it was my mistake to insist. Sorry.

-- 
                                                                Gilles.