[Live-devel] FW packets from RTSP Client

[Emiliano Parasassi]

2006/9/7, Ross Finlayson <finlayson at live555.com>:
>
> >As described in 6.1.2 of this draft of IETF:
> >http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-03
> >
> >[...]
> >     To allow UDP packets to arrive from the server to a client behind a
> >     restricted NAT, the client must send the very first UDP packet to
> >     pinch a hole in the NAT. The client, before sending a RTSP PLAY
> >     request,
> >[...]
> >
> >I wrote this patch that allows RTSPClient to receive RTP/RTCP packets
> >even if they are behind a restricted NAT. I've tested in this
> architecture;
> >
> >RTSPServer <--> Public Router <--> Internet <--> Public Router <-->
> RTSPClient
> >
> >...and seems to work fine.
>
> Thanks for the note.  At some point I hope to add more complete
> STUN/ICE functionality to the RTSP implementation (client and
> server).  In the meantime, if people want to try using your patch,
> then they they may find it useful; thanks for making it available.
>
> A couple of things to note about your patch, however:
> - Your packet data is not valid RTP or RTCP, so has the potential to
> confuse the receiving server, or at least to cause it to log invalid
> incoming data (especially for RTCP).

- You are sending your packet with TTL 0, so you're lucky it leaves
> the local machine, let alone traverses NATs.


It's true, but in the architecture described above, the scope is only to
open an
hole in the first node (the FW), and not to arrive to RTSP Server. However
increment
TTL is right at all.

I hope you'll implement STUN/ICE directives soon, before the ufficial
release of the new
version of Videolan, so it will be possible to use RTSPClient in more
circumstances.

Regards
Emiliano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20060907/2d32597b/attachment.html