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

[Cullen Jennings <[e-mail]>]

> 
> Let me recap:
> We don't have an use case for E2E rtp header extensions

I don't think that is the case. There have been uses discussed that need integrity today and people want to make sure the framework does not limit what can be done in the future. Keep in mind their are lots of header extensions for RTP that are not defined by the IETF. 
> We don't provide a solution for signaling E2E rtp header extensions vs HBH ones

Sure we do - it's SDP. In some case, the MD might have to do a re-offer to bring things into line with what it needs. 
> 
> We don't provide a solution on how to successfully signal/handling different subsets of rtp header extensions and unify the negotiated ids
I think we do 

> 
> 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
When we introduced a way to have HBH and E2E, we provided a provided a way to say which way a header was handled by putting it before or after the OBH. I don't find that very hard to implement. For people that have only HBH headers, it is really easy. 

> 
> We don't expect anyone implementing it

No, there are already implementations of this. 

> Really, I don't see any reason why we have to keep support for E2E rtp header extensions.

Because if you don't design them in now, they are really hard to add later.