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

On 4/25/17 4:19 PM, Nils Ohlmeier wrote:
>
>> On Apr 24, 2017, at 14:30, Sergio Garcia Murillo
>> <sergio.garcia.murillo@gmail.com
>> <mailto:sergio.garcia.murillo@gmail.com>> 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.

This is not really relevant. MDDs do that today without E2E encryption 
and they can continue doing it in the future. I think the point that 
Sergio is making is more about whether or not we have a case where not 
having hdr extensions could somehow compromise a call in a way that 
isn't possible otherwise.

Personally I don't see that.

> 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.

And the only thing this would achieve is to make you think that your 
application is buggy. MDDs has many otherwise to achieve that.

> 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.

Lost you.
>>
>>   * We don't provide a solution for signaling E2E rtp header
>>     extensions vs HBH ones
> So far I always thought the group would “simply” come up with a fixed
> list of header extensions which are E2E, for example orientation and
> audio level. Admitably that might not be a very good solution.

So we are updating 5285 again? Or offer/answer?
I didn't see this in the charter and it seems rather overly ambitious to 
me.

The only solution I can think of is for us to dissociate ourselves from 
SDP here (like we've done for ICE) and say something along the lines of: 
hey we don't currently have an IETF compliant mechanism to let you 
negotiate this, but if you have your own, this is how the transport 
would work.

Emil

>>   * We don't provide a solution on how to successfully signal/handling
>>     different subsets of rtp header extensions and unify the
>>     negotiated ids
> To me this is signaling part I mentioned before. Effectively you have to
> generate new offers from the MDD to align all participants on the IDs.
>>
>>   * 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.
>
> Best
>   Nils
>>
>>   * We don't expect anyone implementing it
>>
>> Really, I don't see any reason why we have to keep support for E2E rtp
>> header extensions.
>>
>> Regards
>> Sergio
>
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>

-- 
https://jitsi.org