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

[Nils Ohlmeier <[e-mail]>]

> On Apr 24, 2017, at 14:30, Sergio Garcia Murillo <[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 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.
> 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.
> 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