[FFmpeg-devel] [PATCH] Send NAT punching packets when starting to read an RTP/UDP stream

Martin Storsjö martin
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 
like this:

udp      17 119 src=192.168.0.104 dst=130.232.81.192 sport=5000 dport=6970 
src=130.232.81.192 dst=194.100.86.5 sport=6970 dport=5000 [ASSURED] use=1 
rate=4806 mark=0 
udp      17 113 src=192.168.0.141 dst=130.232.81.192 sport=5001 dport=6983 
src=130.232.81.192 dst=194.100.86.5 sport=6983 dport=5001 [ASSURED] use=1 
rate=73 mark=0 
udp      17 119 src=192.168.0.141 dst=130.232.81.192 sport=5000 dport=6982 
src=130.232.81.192 dst=194.100.86.5 sport=6982 dport=5000 [ASSURED] use=1 
rate=1903 mark=0 
udp      17 118 src=192.168.0.104 dst=130.232.81.192 sport=5001 dport=6971 
src=130.232.81.192 dst=194.100.86.5 sport=6971 dport=5001 [ASSURED] use=1 
rate=17 mark=0 
udp      17 118 src=192.168.0.104 dst=130.232.81.192 sport=5003 dport=6971 
src=130.232.81.192 dst=194.100.86.5 sport=6971 dport=5003 [ASSURED] use=1 
rate=17 mark=0 
udp      17 112 src=192.168.0.141 dst=130.232.81.192 sport=5003 dport=6983 
src=130.232.81.192 dst=194.100.86.5 sport=6983 dport=5003 [ASSURED] use=1 
rate=73 mark=0 
udp      17 119 src=192.168.0.141 dst=130.232.81.192 sport=5002 dport=6982 
src=130.232.81.192 dst=194.100.86.5 sport=6982 dport=5002 [ASSURED] use=1 
rate=14005 mark=0 

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
> situation.

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 
complex...

// Martin



More information about the ffmpeg-devel mailing list