relaxing rtp packet probation

[Aleix Conchillo Flaqué]

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Aleix Conchillo Flaqué]

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?

Thanks,

Aleix

On Tue, Aug 21, 2012 at 2:50 PM, Aleix Conchillo Flaqué
<[hidden email]> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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é
> <[hidden email]> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel