Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP

[Colin Perkins <[e-mail]>]

On 21 Apr 2015, at 11:08, Harald Alvestrand <[e-mail]> wrote:
> Den 21. april 2015 11:52, skrev Magnus Westerlund:
>> Hi,
>> 
>> I think I have a more specific proposal of how to deal with this case
>> regarding the circuit breakers and legacy peer end-point that don't send
>> RTCP. I think it is important that we consider these legacy gatewaying
>> cases. Unfortunately there appear to be a lot of audio RTP senders that
>> don't send RTCP.
>> 
>> Proposal:
>> 
>> In case circuit breaker #2 RTCP Timeout is triggered and;
>> - No RTCP at all has been received;
>> - This endpoint neither sends nor receive more than 72 kbps of RTP
>>   payload data on average over a 5 second window per direction;
>> 
>> then this triggering of the circuit breaker MAY be ignored. This would
>> be done if it is desired to support legacy RTP sender that lacks RTCP
>> implementations.
>> 
>> 
>> 
>> The motivation for the above formulation is really to make it clear that
>> this is only for legacy, and not create a situation where ignoring the
>> circuit breaker is okay, even if RTCP is being received, just because
>> one are in a really low-rate situation.
>> 
>> I wonder if the above should go into the RTP usage or into the circuit
>> breaker document itself?
> 
> 
> I think it belongs to advice on gatewaying, actually - and that gateways
> should be prepared to do RTCP synthesis in this situation.
> 
> Perpetuating tolerance for the broken behavior of ignoring "MUST send
> RTCP" seems like a path that doesn't lead to getting rid of the behavior
> in the end.

I tend to agree: this seems like something where the gateway ought to handle the interoperability, and synthesise appropriate RTCP. 

Or, if that's really too onerous, tie into some other consent check that can indicate that the flow is still wanted and not causing problems.

-- 
Colin Perkins
https://csperkins.org/