2006/9/7, Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>As described in 6.1.2 of this draft of IETF:<br>><a href="http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-03">http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-03</a><br>><br>>[...]<br>> To allow UDP packets to arrive from the server to a client behind a
<br>> restricted NAT, the client must send the very first UDP packet to<br>> pinch a hole in the NAT. The client, before sending a RTSP PLAY<br>> request,<br>>[...]<br>><br>>I wrote this patch that allows RTSPClient to receive RTP/RTCP packets
<br>>even if they are behind a restricted NAT. I've tested in this architecture;<br>><br>>RTSPServer <--> Public Router <--> Internet <--> Public Router <--> RTSPClient<br>><br>>...and seems to work fine.
<br><br>Thanks for the note. At some point I hope to add more complete<br>STUN/ICE functionality to the RTSP implementation (client and<br>server). In the meantime, if people want to try using your patch,<br>then they they may find it useful; thanks for making it available.
<br><br>A couple of things to note about your patch, however:<br>- Your packet data is not valid RTP or RTCP, so has the potential to<br>confuse the receiving server, or at least to cause it to log invalid<br>incoming data (especially for RTCP).
</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- You are sending your packet with TTL 0, so you're lucky it leaves<br>the local machine, let alone traverses NATs.
</blockquote><div><br>It's true, but in the architecture described above, the scope is only to open an<br>hole in the first node (the FW), and not to arrive to RTSP Server. However increment<br>TTL is right at all.<br><br>
I hope you'll implement STUN/ICE directives soon, before the ufficial release of the new<br>version of Videolan, so it will be possible to use RTSPClient in more circumstances.<br><br>Regards<br>Emiliano<br><br></div></div>