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

["Paul E. Jones" <[e-mail]>]

I don't see how we can support any E2E extension given the offerer specifies the ID mapping. Multiple endpoints in a conference might indicate any number of didn't ID values for the same extension.

I think we should remove support for E2E extensions.  We could leave it open for future support, but I think we should require insertion of the OHB before any other extensions to force HBH use only.

Paul


-------- Original Message --------
From: Cullen Jennings <[e-mail]>
Sent: May 11, 2017 8:05:58 PM EDT
To: Sergio Garcia Murillo <[e-mail]>
Cc: Richard Barnes <[e-mail]>, Nils Ohlmeier <[e-mail]>, "[e-mail]" <[e-mail]>, Jonathan Lennox <[e-mail]>
Subject: Re: [Perc] Drop support for E2E RTP header extensions


OK, I think I see what is causing the confusion...

For a given header extension like say "urn:3gpp:video-orientation:6" you are thinking that there needs to be a way for the conference system to tell the endpoint if that given header is E2E encrypted or only HBH. That is not how PERC is working, PERC has the specification on header extensions when used in a PERC context tell the thing sending the RTP what it needs to do or leaving it as an implementation choice. The endpoint or browser is compiling that decisions in to the code. 

Of course the SDP can be used to decide if "urn:3gpp:video-orientation:6" is in use or not but not how it is encrypted. 



> On May 9, 2017, at 9:15 AM, Sergio Garcia Murillo <[e-mail]> wrote:
> 
> 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?

Uh, not getting what you mean by E2E here ? An example of something that in some case might want end to end integrity is urn:3gpp:roi-sent

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