Re: [Perc] Drop support for E2E RTP header extensions

[Sergio Garcia Murillo <[e-mail]>]

On 25/04/2017 23:19, Nils Ohlmeier wrote:
>
>> On Apr 24, 2017, at 14:30, Sergio Garcia Murillo 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Let me recap:
>>
>>   * We don't have an use case for E2E rtp header extensions
>>
> There are things like audio level and video orientation, which make 
> more sense to be passed along by the MDD, rather then re-write them. I 
> guess in worst case a malicious MDD which re-writes all extension 
> headers could always mark my audio packet with a very low level, so 
> that I never become the active speaker.
The extension is named "client to mixer audio level" and it is by 
definition HBH as it is required by the SFU in order to work properly. 
There is another *different* extension for "client to mixer audio level" 
which is also HBH.

Video orientation is the only extension that makes sense to be e2e, but 
i don't think that it justifies all the effort required to implement it, 
and could be HBH and copied over by the SFU as it is done today. It can 
also safely disabled with just a little overhead on sender side to 
rotate the videos in origin. Which I think it is the safest method 
anyway today as AFAIK firefox doesn't support it yet, so it is better to 
be disabled.

> The one use case I have come up with so far, which hasn’t been propose 
> AFAIK, would be an extension to prove the identity of the sender for 
> each RTP packet send with asymmetric keys.

I think that we can find much better solutions for that than a new rtp 
header extension.

[...]
>>
>>   * We introduce a new concept of rtp header ordering that is not
>>     defined anywhere and is not supported by anyone currently making
>>     implementation much more difficult
>>
> Indeed the fact that suddenly the order of negotiated header 
> extensions matters changes probably how most existing implementations 
> add extensions to the RTP packets. Obviously it would be ideal if we 
> can propose new standard which require no or little changes. This 
> appears to be not the case here unfortunately.

That is the problem when there is not a use case, that it is not 
possible to find a solution that fulfills it.

Best regards
Sergio