[asterisk-dev] strictrtp seems to be not so strict

[Torrey Searle]

I wouldn't dare change the default :-)

But the way I understand the code is that it would end up being a
switching, as getting a packet from the current source doesn't seem to
re-set the counter.

I'll do the following,
change the conf validation to allow probation = 0  (default will remain 4)

if learning_min_sequential is 0, the else in

        if (rtp->strict_rtp_state == STRICT_RTP_CLOSED) {
                if (!ast_sockaddr_cmp(&rtp->strict_rtp_address, &addr)) {

will be disabled

On 26 August 2016 at 14:05, Joshua Colp <jcolp at digium.com> wrote:

> Torrey Searle wrote:
>
>> I'm looking at the implementation of strictrtp and it seems currently
>>   there is no way disable re-learning in it.  My concern is from a
>> security aspect, if somebody sends enough rtp packets to asterisk, he
>> can have the audio stream redirected to himself.
>>
>> This could be mitigated possibly by setting the probation to a very high
>> value, but I was wondering if it would be interesting to allow probation
>> = 0 to disable the functionality to re-learn.  (exception for symmetric
>> rtp and ice, but that is already in place in the code)
>>
>
> I think it would be a fine addition to have more control over it, but I
> wouldn't change the default.
>
> You'd also likely either end up not switching to the new source with the
> current code, or end up in a fight where it keeps switching it looks like.
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20160826/398f8f1a/attachment.html>