[FFmpeg-devel] [PATCH] Send NAT punching packets when starting to read an RTP/UDP stream
Thu Feb 11 10:53:09 CET 2010
On Thu, 11 Feb 2010, Luca Abeni wrote:
> Martin Storsj? wrote:
> > > The packets pass through the NAT, and arrive to S from a different source
> > > IP (the NAT public IP) and a different source port (the port on which the
> > > NAT machine remaps the "private" source port used by C).
> > If the NAT changes the port numbers, this probably doesn't work. Usually,
> > they don't change the port numbers, though. The "source port, destination
> > port, destination ip" tuple is often enough to keep track of connections,
> > mapping them uniquely to the private IP of C.
> But if you have two NATed clients sending packets from the same source
> port, won't the source port of at least one of the two be changed?
> Consider two ffmpeg clients in the local network, which want to
> receive the same stream...
No, as long as the destination port or IP is different, it's ok for the
linux conntrack/nat system, it seems.
I tested this, two machines behind the same NAT, streaming with identical
ffmpeg versions from the same RTSP server. Since the RTSP server allocates
the UDP ports on the server, they're different for each stream.
The relevant lines from /proc/net/ip_conntrack on the NAT router looked
udp 17 119 src=192.168.0.104 dst=184.108.40.206 sport=5000 dport=6970
src=220.127.116.11 dst=18.104.22.168 sport=6970 dport=5000 [ASSURED] use=1
udp 17 113 src=192.168.0.141 dst=22.214.171.124 sport=5001 dport=6983
src=126.96.36.199 dst=188.8.131.52 sport=6983 dport=5001 [ASSURED] use=1
udp 17 119 src=192.168.0.141 dst=184.108.40.206 sport=5000 dport=6982
src=220.127.116.11 dst=18.104.22.168 sport=6982 dport=5000 [ASSURED] use=1
udp 17 118 src=192.168.0.104 dst=22.214.171.124 sport=5001 dport=6971
src=126.96.36.199 dst=188.8.131.52 sport=6971 dport=5001 [ASSURED] use=1
udp 17 118 src=192.168.0.104 dst=184.108.40.206 sport=5003 dport=6971
src=220.127.116.11 dst=18.104.22.168 sport=6971 dport=5003 [ASSURED] use=1
udp 17 112 src=192.168.0.141 dst=22.214.171.124 sport=5003 dport=6983
src=126.96.36.199 dst=188.8.131.52 sport=6983 dport=5003 [ASSURED] use=1
udp 17 119 src=192.168.0.141 dst=184.108.40.206 sport=5002 dport=6982
src=220.127.116.11 dst=18.104.22.168 sport=6982 dport=5002 [ASSURED] use=1
So yes, the source ports for multiple connections are the same, but since
the destination ports or destination IP differ, they're treated as
different connections, and no port remapping is done.
> I've seen a good number of NATs remapping the port numbers in this
Well, if they do, this solution doesn't work, no, but it didn't work in
the first place either. A solution covering that case would be much more
More information about the ffmpeg-devel