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

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

On 09/05/2017 18:07, Cullen Jennings wrote:
>>
>> 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.
One thing is integrity and another is E2E. Could you name some of those 
use cases?

>>   * 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.
No, the SDP only negotiates HBH extensions. You can't negotiate that 
some will be HBH and some E2E, it is up to the endpoints to decide when 
they create the RTP packet, and it won't be known by the MD before hand 
just by the SDP.

>>  *
>>
>>
>>   * 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
Where?


>>  *
>>
>>
>>
>>   * 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.
Well, I have modified libwertc and jitsi code, and I can tell you it is 
not the case. Neither on my own MCU/SFU.

Best regards
Sergio