[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

[Luca Abeni]

On 09/28/2010 09:37 AM, Martin Storsj? wrote:
> 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)
Ok, sorry. I remember using a libav-based application for receiving RTP
traffic on a machine with multiple network cards... But I probably had
some local patches for that.

> - the host specified in the url is the remote peer, not the local
> address to bind to.
My impression was that for "read only" URLs it was the local address,
but again I might be wrong.

>>>> 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?
Looks ok to me. According to what you write above, this would be a new
feature, so it can be implemented in a different patch :)


				Luca