[FFmpeg-devel] [PATCH] Add code in rtpproto.c/udp.c to test incoming packets against the host/port looked up in rtp/udp_set_remote_url

[Martin Storsjö]

On Tue, 28 Sep 2010, Luca Abeni wrote:

> On 09/27/2010 06:51 PM, Martin Storsj? wrote:
> [...]

> > I do agree that there might be cases where the remote IP isn't known, 
> > but this seems to be solved by using e.g. rtp://0.0.0.0:4242/ in the 
> > patch suggested.
> 
> The problem is: assume that my computer has 2 different network cards,
> eth0 and eth1, and the address of eth0 is 192.168.10.20. If I want to
> receive RTP traffic on port 4242 of eth0, I think the right URL would
> be rtp://192.168.10.20:4242, or similar... Using 0.0.0.0:4242 would
> result in receiving packets from both eth0 and eth1.

With the current code, you will be receiving packets on both eth0 and eth1 
regardless of which of the URLs you specify. We always currently bind to 
INADDR_ANY (and similar for ipv6) - the host specified in the url is the 
remote peer, not the local address to bind to.

> > > It is perfectly valid for a packet to come from another source
> > > in some situations.
> > 
> > Yes, in some situations. If we want that to be the default, that's
> > probably quite ok, then we'd just have to enable this "only accept packets
> > coming from the peer we've specified in the URL" feature with some
> > flag/option.
> 
> I think this is a good idea. Maybe we can add a "remote_addr=" tag
> to the URL? (I think I read a similar suggestion in some email,
> but I might be wrong :)

I think the way things currently work, the remote address is the one 
specified in the URL, if you specifically want to bind to a particular 
local address, perhaps that should be done via local_addr= instead? The 
same goes for local vs remote port currently, currently one specifies
rtp://1.2.3.4:7000?local_port=8000, to send packets to 1.2.3.4 to port 
7000, from port 8000 locally.

// Martin