relaxing rtp packet probation

[Wim Taymans]

On 08/22/2012 03:27 AM, Aleix Conchillo Flaqué wrote:
> Forgot to mention that other options would be:
>
> - analyze, let's say, 10 packets, sort them and check for sequence numbers.
> - simply disabling the probation as requested by the user.
> ...
>
> Another question would be is the probation really necessary?
It gives some protection against attacks where random packets are sent 
to your port.
Without probation you would end up with a lot of new validated SSRCs 
that can fill up
your participant table (and memory) pretty quickly. Unvalidated sources 
(in probation)
are supposed to use very little resources and are cleaned up very quickly.

A clever attacker can of course work around this very easily. There are 
other ways of
protecting against these kinds of attacks (like for example RFC2762).

The RFC says that the amount of sequential packets in probation should 
be configurable
so I would not mind a patch that allows you to configure the probation 
value.

Wim

>
> Thanks,
>
> Aleix
>
> On Tue, Aug 21, 2012 at 2:50 PM, Aleix Conchillo Flaqué
> <aconchillo at gmail.com> wrote:
>> Hi,
>>
>> I am streaming (via rtp) jpeg images every 4 seconds and everything
>> worked fine until network latency jitter was setup (using tc command).
>> The server is implemented with gst-rtsp-server and the client simply
>> uses rtsprc element.
>>
>> Digging around rtp code I found out that
>> gst-plugins-good/gst/rtpmanager/rtpsource.c does a probation to
>> determine if we have a valid RTP stream. Until that probation succeeds
>> no packets are pushed to other elements.
>>
>> The current probation algorithm expects receiving a couple of sets of
>> 2 packets with consecutive sequence numbers. The problem with my jpeg
>> stream and network configuration is that it sends few packets every
>> time and none of the packets have consecutive sequence numbers. This
>> means that the probation will always fail. Setting a higher latency
>> does not help as the probation is done even before the
>> gstrtpjitterbuffer receives the packets.
>>
>> Attached, there's a patch that relaxes that probation a bit by adding
>> a threshold. So, it expects a couple of sets of 2 packets with
>> consecutive numbers considering a threshold of 2, thus receiving a
>> packet with sequence number 3 and then a packet with sequence number 5
>> is considered valid.
>>
>> I am new to this code, but the patch actually works. I am probably
>> missing lots of things here. So any help would be appreciated.
>>
>> Thanks in advance,
>>
>> Aleix
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel