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

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 12:36:35 +0200

Hi all,

I have seen no more activity regarding the E2E RTP header issue.

Is there a consensus that they can't be supported and that there is no 
use case for them? Does anyone have a different view? Should this be 
discussed and agreed on next virtual interim meeting?

Best regards

Sergio

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 24 Apr 2017 15:38:51 +0000

> On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Hi all,
> 
> Is there a consensus that they can't be supported and that there is no use case for them? Does anyone have a different view? Should this be discussed and agreed on next virtual interim meeting?

At previous virtual interims, I believe the consensus was that no one had a current use case for E2E RTP header extensions; however, if we didn’t support them, retrofitting them into the protocol later would be extremely difficult.  Thus, we (reluctantly) decided to support them.

If they turn out to complicate the protocol too much, I suppose this can be revisited.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 17:46:36 +0200

> If they turn out to complicate the protocol too much, I suppose this can be revisited.

Hi Jonathan, thanks for the heads up.

Apart of making protocol complex, the way that rtp header extensions are 
supported on double encryption won't work on E2E mode except on the most 
trivial scenarios. So, I expect that either we drop support or find a 
way to fix it.

Best regards

Sergio

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Apr 2017 11:52:33 -0400

On Mon, Apr 24, 2017 at 11:46 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

>> At previous virtual interims, I believe the consensus was that no one had
>> a current use case for E2E RTP header extensions; however, if we didn’t
>> support them, retrofitting them into the protocol later would be extremely
>> difficult.  Thus, we (reluctantly) decided to support them.
>>
> trivial scenarios.

Since we're talking about E2E protection, it seems like the only scenario
is "the header travels unmodified from sender to receiver".  It seems like
this is supported in the simplest way possible; all the E2E headers are
grouped together, before the OHB.  Beyond the OHB, you can do whatever you
want.

What advanced scenarios are not supported here?

--Richard

> So, I expect that either we drop support or find a way to fix it.
>
> Best regards
>
> Sergio
>
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 17:57:48 +0200

On 24/04/2017 17:52, Richard Barnes wrote:
>
>
> On Mon, Apr 24, 2017 at 11:46 AM, Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>             On Apr 24, 2017, at 6:36 AM, Sergio Garcia Murillo
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             Hi all,
>
>             Is there a consensus that they can't be supported and that
>             there is no use case for them? Does anyone have a
>             different view? Should this be discussed and agreed on
>             next virtual interim meeting?
>
>         At previous virtual interims, I believe the consensus was that
>         no one had a current use case for E2E RTP header extensions;
>         however, if we didn’t support them, retrofitting them into the
>         protocol later would be extremely difficult.  Thus, we
>         (reluctantly) decided to support them.
>
>     Apart of making protocol complex, the way that rtp header
>     extensions are supported on double encryption won't work on E2E
>     mode except on the most trivial scenarios. 
>
>
> Since we're talking about E2E protection, it seems like the only 
> scenario is "the header travels unmodified from sender to receiver".  
> It seems like this is supported in the simplest way possible; all the 
> E2E headers are grouped together, before the OHB.  Beyond the OHB, you 
> can do whatever you want.
>

RTP header extensions are negotiated on the SDP O/A, so not all 
endpoints may support same header extension, and even if they support 
same set of extensions, they may be negotiated with different ids. So it 
is impossible to support RTP header extensions E2E except in the 
scenario in which all endpoints support same subset of extensions and 
happens to be negotiated with same id.

Best regards
Sergio

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 24 Apr 2017 13:57:30 -0700

> On Apr 24, 2017, at 08:57, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> RTP header extensions are negotiated on the SDP O/A, so not all endpoints may support same header extension, and even if they support same set of extensions, they may be negotiated with different ids. So it is impossible to support RTP header extensions E2E except in the scenario in which all endpoints support same subset of extensions and happens to be negotiated with same id.

The topic of header extensions has been discussed in the past at the first perc interim meeting on 2016-01-11. I suggest reading the meeting minutes and materials from that meeting: https://datatracker.ietf.org/group/perc/meetings/ <https://datatracker.ietf.org/group/perc/meetings/>
It appears at the time discussion on RTCP had not concluded yet. But I don’t think that the conclusion of doing RTCP hop-by-hop only changes substantially the arguments to allow end-to-end header extensions.

I assume nobody disagrees that negotiating end-to-end header extension is not easy. But it is purely a signaling problem. I don’t see a technical reason why the media plane should dis-allowed it.
As it is a signaling issue it also means that every PERC conferencing solution is free to remove end-to-end header extension from the signaling if it wants to make it’s life easier.

Best
  Nils Ohlmeier

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 23:30:27 +0200

On 24/04/2017 22:57, Nils Ohlmeier wrote:
>
>> On Apr 24, 2017, at 08:57, Sergio Garcia Murillo 
>> same set of extensions, they may be negotiated with different ids. So 
>> it is impossible to support RTP header extensions E2E except in the 
> The topic of header extensions has been discussed in the past at the 
> first perc interim meeting on 2016-01-11. I suggest reading the 
> meeting minutes and materials from that meeting: 
> https://datatracker.ietf.org/group/perc/meetings/
> It appears at the time discussion on RTCP had not concluded yet. But I 
> don’t think that the conclusion of doing RTCP hop-by-hop only changes 
> substantially the arguments to allow end-to-end header extensions.
>
> I assume nobody disagrees that negotiating end-to-end header extension 
> is not easy. But it is purely a signaling problem. I don’t see a 
> technical reason why the media plane should dis-allowed it.
> As it is a signaling issue it also means that every PERC conferencing 
> solution is free to remove end-to-end header extension from the 
> signaling if it wants to make it’s life easier.
>

Let me recap:

  * We don't have an use case for E2E rtp header extensions
  * We don't provide a solution for signaling E2E rtp header extensions
    vs HBH ones
  * We don't provide a solution on how to successfully signal/handling
    different subsets of rtp header extensions and unify the negotiated 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
  * 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

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 25 Apr 2017 14:19:02 -0700

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 25 Apr 2017 16:28:17 -0500

On 4/25/17 4:19 PM, Nils Ohlmeier wrote:
>
>> On Apr 24, 2017, at 14:30, Sergio Garcia Murillo
> 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

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

-- 
https://jitsi.org

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 26 Apr 2017 01:25:38 +0200

On 25/04/2017 23:19, Nils Ohlmeier wrote:
> 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 extension is named "client to mixer audio level" and it is by 
definition HBH as it is required by the SFU in order to work properly. 
There is another *different* extension for "client to mixer audio level" 
which is also HBH.

Video orientation is the only extension that makes sense to be e2e, but 
i don't think that it justifies all the effort required to implement it, 
and could be HBH and copied over by the SFU as it is done today. It can 
also safely disabled with just a little overhead on sender side to 
rotate the videos in origin. Which I think it is the safest method 
anyway today as AFAIK firefox doesn't support it yet, so it is better to 
be disabled.

> each RTP packet send with asymmetric keys.

I think that we can find much better solutions for that than a new rtp 
header extension.

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

That is the problem when there is not a use case, that it is not 
possible to find a solution that fulfills it.

Best regards
Sergio