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

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 May 2017 09:07:56 -0700

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 9 May 2017 18:15:14 +0200

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 11 May 2017 17:05:58 -0700

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 <[email-masked]> wrote:
> 
> 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

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 12 May 2017 02:10:34 -0400

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 12 May 2017 10:18:12 +0200

On 12/05/2017 2:05, Cullen Jennings wrote:
> 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.
>
And that will cause problems. If the MD requires an extension to be HBH 
in order to be properly and the endpoint send it E2E, or some E2E and 
others HBH. If we decide to support E2E header extensions we have to 
provide a mechanism on the SDP to negotiate them. We just can leave it 
as an implementation choice.

> 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.
>
(more on this below)

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

I mean E2E encrypted. Currently E2E extensions are not encrypted, just 
integrity protected. The MD will still be able to read their contents, 
but not modify it. AFAIK, if we want to encrypt them we would also need 
to support RFC 6904 when applying the inner crypto.

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 12 May 2017 10:35:05 +0200

On 12/05/2017 8:10, Paul E. Jones wrote:
> 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.
>
Moreover, different endpoints may support different extensions, and they 
can join/leave the the conference at any given time.

So the SFU will not only have to renegotiate de ids of the extensions 
(is that even allowed?), it will have to keep a dynamic list of the 
common extensions and renegotiate it with all participants each time 
each time on of them enters/leaves.

Also, as there is no way of knowing which extensions are HBH and which 
are E2E and which ones are HBH, so the SFU won't be able to use a HBH 
extension with one peer (for example the custom chrome extensions for 
sender side bandwidth estimation) except if all other participants also 
support it, and will have to stop using it if for example a firefox 
participant joins. Even if it is not mean to be used E2E.

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

I am against changing the way rtp header extensions are supported today 
by forcing strict ordering "just in case" not even knowing if e2e 
extension will ever be supported, and if so, if this is going to be the 
mechanism used to support it.

Best regards
Sergio

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 May 2017 08:33:35 -0600

> On May 12, 2017, at 12:10 AM, Paul E. Jones <[email-masked]> wrote:
> 

Just so we are all clear on how this would work ... sorry for the repetition ....

If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and ID of 1 and the conferences wants to use 22 because that is what other endpoints are using, the conference server simply rejects that in the answer then does and reoffers that with an ID of 22. 

This of course does not take care of Sergio request that the conference bridge would like to tell ALice's UA if this should be protected E2E or not. I'll send a separate email on that.

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 13 May 2017 09:04:42 -0600

So if the MD requires the extension to be modifiable and the client does not want that, you are right, it is not going to work. I few this as a feature not a bug. I think that when the extensions is defined for use in the PERC framework, we need to decide which category it is in. The basic premise of the PERC is we do not fully trust the MD so letting the MD decide what it can parts of the RTP it is allowed to modify has some problems. That said, I agree it is possible that in the future there might be an extension where we do need the MD to be able to control which way it is handled and in that case, that extension could define SDP to negotiate that. 

The WG discussed the requirements around this along and you see the consensus of the  01.11.2016 meeting at https://www.ietf.org/proceedings/interim-2016-perc-01/minutes/minutes-interim-2016-perc-1

Some things that were marked as needing E2E integrity are the video orientation (CVO) and the synchronization metadata. I don't see anything that would cause us to change the desire to have E2E integrity for theses. 

> On May 12, 2017, at 2:18 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> And that will cause problems. If the MD requires an extension to be HBH in order to be properly and the endpoint send it E2E, or some E2E and others HBH. If we decide to support E2E header extensions we have to provide a mechanism on the SDP to negotiate them. We just can leave it as an implementation choice.
> 
>>> [...] One thing is integrity and another is E2E. Could you name some of those use cases?
>> 
> I mean E2E encrypted. Currently E2E extensions are not encrypted, just integrity protected. The MD will still be able to read their contents, but not modify it. AFAIK, if we want to encrypt them we would also need to support RFC 6904 when applying the inner crypto. 

yes, agree, and the framework drafts says 

   If there is a need to encrypt one or more RTP header extensions end-
   to-end, an encryption key is derived from the end-to-end SRTP master
   key to encrypt header extensions as per [RFC6904].

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 13 May 2017 17:43:55 +0200

> This of course does not take care of Sergio request that the conference bridge would like to tell ALice's UA if this should be protected E2E or not. I'll send a separate email on that.

But as there is no way to know if any extension is E2E and HBH, the MD 
will have to reject all extensions always, and re offer them with the 
common ids. Also, for the same reason, if we want to avoid sending 
unknown extensions to all the peers, the MD will have to disable any 
extension not available to all the peers on the conference, and do it 
dynamically. That means, each time a participant joins which does not 
support an extension for the common set, it will have to re-offer to all 
other participants to remove it

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 13 May 2017 17:58:41 +0200

> Some things that were marked as needing E2E integrity are the video orientation (CVO) and the synchronization metadata. I don't see anything that would cause us to change the desire to have E2E int…

Well, except that CVO only makes sense if ALL participants in the 
conference supports it, if not, the ones not supporting the extension 
will see the image not rotated. As of today, Firefox does not yet 
support it, so the reality is the CVO is not used at all on SFU 
conferences.

Sorry to ask, what is the synchronization metadata?

Best regards
Sergio

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 14 May 2017 00:08:35 +0000

Cullen,

I say we should NOT support E2E extensions.  Make them HBH and the MDD 
can re-write header extensions values or remove them as it sees fit.

Sergio, you want E2E extensions?  Seems like it's going to be rather 
complicated to support with the current design.

Paul

------ Original Message ------
From: "Cullen Jennings" <[email-masked]>
To: "Paul Jones" <[email-masked]>
Cc: [email-masked]
Sent: 5/13/2017 10:33:35 AM
Subject: Re: [Perc] Drop support for E2E RTP header extensions

>If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and ID of 
>1 and the conferences wants to use 22 because that is what other 
>endpoints are using, the conference server simply rejects that in the 
>answer then does and reoffers that with an ID of 22.
>
>This of course does not take care of Sergio request that the conference 
>bridge would like to tell ALice's UA if this should be protected E2E or 
>not. I'll send a separate email on that.
>
>
>_______________________________________________
>Perc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/perc

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 May 2017 07:34:42 -1000

So let me just confirm one thing with both of you (Paul & Sergio) ... you understand that the current design supports both E2E and HbH header extensions and which way a given extension is handed is currently determined by specification of the system not negotiated over SDP? 

Yes we could change any of that but I just want to make sure we are all on the same page of where we are now 

> On May 13, 2017, at 2:08 PM, Paul E. Jones <[email-masked]> wrote:
> 
> Cullen,
> 
> I say we should NOT support E2E extensions.  Make them HBH and the MDD can re-write header extensions values or remove them as it sees fit.
> 
> Sergio, you want E2E extensions?  Seems like it's going to be rather complicated to support with the current design.
> 
> Paul
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 15 May 2017 20:18:29 +0200

> So let me just confirm one thing with both of you (Paul & Sergio) ... you understand that the current design supports both E2E and HbH header extensions and which way a given extension is handed is…

Yes, I fully understand that current proposal provides a mechanism to 
transport both E2E and HBH extensions between the participants and the MD.

Also I understand that there has been not a single use case provided for 
E2E extensions and that current proposal has issues and omits key parts 
so that makes it impossible to implement E2E extension handling on an SFU.

Best regards
Sergio

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 May 2017 19:45:02 +0000

Cullen,

I understand that was a goal at the outset.  However, I'm not sure the 
specs as they current exist will allow us to do that, but feel free to 
correct me if I'm wrong.

The issue, as I understand, is the requirement in RFC 5285 that says:
    A session update MAY add or remove extension(s). Identifiers values 
in the valid range MUST NOT be altered (remapped).

The offerer will suggest an ID mapping to extensions and the MD cannot 
change that mapping.   A dozen endpoints can offer different ID mappings 
for the same or overlapping extensions.  The extensions (including 
encrypted extensions) can be preserved before the OHB, but it's unclear 
to me how the endpoint would process those.  If the receiving endpoint 
sent an offer indicating it wanted to use extension "foo" with ID=6 and 
the sender of the particular RTP packet sent an offer for "foo" with an 
ID=5, then the receiver is not going be in agreement with the ID mapping 
of the sender.

A solution could be to introduce an "extension remapping extension".  
For example, the receiver would skip over all extensions until it gets 
to the OHB.  It would then look for the "extension remapping extension" 
that would tell the receiver (in my example above) that "ID=6 is 
remapped to ID=5 before the OHB".  So, while the receiver had assumed 
ID=6 would be "foo", it would look before the OHB for ID=5.  In effect, 
this is creating a way to get around that statement in RFC 5285 that 
disallows remapping.

AFAIK, we don't have language like that in any document and I don't 
think the MD is otherwise able to force all endpoints to use a common 
mapping.

Paul

------ Original Message ------
From: "Cullen Jennings" <[email-masked]>
To: "Paul Jones" <[email-masked]>; "Sergio Garcia Murillo" 
<[email-masked]>
Cc: [email-masked]
Sent: 5/15/2017 1:34:42 PM
Subject: Re: [Perc] Drop support for E2E RTP header extensions

>
>So let me just confirm one thing with both of you (Paul & Sergio) ... 
>you understand that the current design supports both E2E and HbH header 
>extensions and which way a given extension is handed is currently 
>determined by specification of the system not negotiated over SDP?
>
>>  I say we should NOT support E2E extensions.  Make them HBH and the 
>>MDD can re-write header extensions values or remove them as it sees 
>>fit.
>>
>>>  If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and ID 
>>>of 1 and the conferences wants to use 22 because that is what other 
>>>  This of course does not take care of Sergio request that the 
>>>conference bridge would like to tell ALice's UA if this should be 
>>>protected E2E or not. I'll send a separate email on that.
>>>
>>>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 16 May 2017 09:17:46 -1000

Paul, 

I think you are wrong but let me know what parts of this you don't think work and we can work through it. 

So lets split up a bunch of different ways a conference systems that uses the PERC stuff can do this.

1) for any extensions that are HbH, the MD can simply remap them if it wants 

2) for any extensions in the offer that are E2E, if they are not needed for this conferences, the MD can simply reject them in the SDP offer/answer and there will be no E2E extensions. 

3) for both HbH and E2E exertions, to repeat my prev email on this thread from May 13,
> If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and ID of 1 and the conferences wants to use 22 because that is what other endpoints are using, the conference server simply rejects that in the answer then does a reoffers with an ID of 22. 

Note that point 2 is very close to what  Sergio is arguing for here ...  one thing he might do in his implementation is simply make sure that if and endpoint attempts to negotiate an extension other than the ones his MD supports, make the MD rejects that extension. At that point his MD will not need to deal with any E2E stuff and there is not ordering.  

Some systems that support extension might want to do 1 while others might want to do 3. Some systems might want to reject every extension other than client-to-mixer audio levels.

I think the specs as they are support 1, 2, and 3 - am I missing something ?

> On May 15, 2017, at 9:45 AM, Paul E. Jones <[email-masked]> wrote:
> 
> Cullen,
> 
> I understand that was a goal at the outset.  However, I'm not sure the specs as they current exist will allow us to do that, but feel free to correct me if I'm wrong.
> 
>   A session update MAY add or remove extension(s). Identifiers values in the valid range MUST NOT be altered (remapped).
> 
> The offerer will suggest an ID mapping to extensions and the MD cannot change that mapping.   A dozen endpoints can offer different ID mappings for the same or overlapping extensions.  The extensions (including encrypted extensions) can be preserved before the OHB, but it's unclear to me how the endpoint would process those.  If the receiving endpoint sent an offer indicating it wanted to use extension "foo" with ID=6 and the sender of the particular RTP packet sent an offer for "foo" with an ID=5, then the receiver is not going be in agreement with the ID mapping of the sender.
> 
> A solution could be to introduce an "extension remapping extension".  For example, the receiver would skip over all extensions until it gets to the OHB.  It would then look for the "extension remapping extension" that would tell the receiver (in my example above) that "ID=6 is remapped to ID=5 before the OHB".  So, while the receiver had assumed ID=6 would be "foo", it would look before the OHB for ID=5.  In effect, this is creating a way to get around that statement in RFC 5285 that disallows remapping.
> 
> AFAIK, we don't have language like that in any document and I don't think the MD is otherwise able to force all endpoints to use a common mapping.
> 
> Paul
> 
> To: "Paul Jones" <[email-masked]>; "Sergio Garcia Murillo" <[email-masked]>
> Cc: [email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Tue, 16 May 2017 14:46:20 -0500

> I think the specs as they are support 1, 2, and 3 - am I missing something ?

What happens when Alice also insists on using a specific ID?

Emil

-- 
https://jitsi.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 16 May 2017 19:51:27 +0000

Cullen,

Step (3) is an issue, because rejecting the offer will likely lead to 
confusion.  The rejection would have to be detailed enough to say "I 
don't want you to use ID=1 for 'foo'.  I want you to use ID=4 for that." 
  Basically, the media distributor would need to reject the offer and 
return an ID map for what it wants to see used.  How do we prevent 
another offer from simply offering a different ID map that is not 
acceptable?

This would also mean that all of the conference servers in a large 
cascaded conference are in agreement on the set of values.  Perhaps that 
is doable if there we assume only one vendor's media distributors will 
be present in a conference.

Paul

------ Original Message ------
From: "Cullen Jennings" <[email-masked]>
To: "Paul Jones" <[email-masked]>
Cc: "Sergio Garcia Murillo" <[email-masked]>; 
[email-masked]
Sent: 5/16/2017 3:17:46 PM
Subject: Re: [Perc] Drop support for E2E RTP header extensions

>2) for any extensions in the offer that are E2E, if they are not needed 
>for this conferences, the MD can simply reject them in the SDP 
>offer/answer and there will be no E2E extensions.
>
>>answer then does a reoffers with an ID of 22.
>
>
>Note that point 2 is very close to what  Sergio is arguing for here ... 
>  one thing he might do in his implementation is simply make sure that 
>if and endpoint attempts to negotiate an extension other than the ones 
>his MD supports, make the MD rejects that extension. At that point his 
>MD will not need to deal with any E2E stuff and there is not ordering.
>
>Some systems that support extension might want to do 1 while others 
>might want to do 3. Some systems might want to reject every extension 
>other than client-to-mixer audio levels.
>
>>  I understand that was a goal at the outset.  However, I'm not sure 
>>the specs as they current exist will allow us to do that, but feel 
>>free to correct me if I'm wrong.
>>
>>  The offerer will suggest an ID mapping to extensions and the MD 
>>cannot change that mapping.   A dozen endpoints can offer different ID 
>>mappings for the same or overlapping extensions.  The extensions 
>>(including encrypted extensions) can be preserved before the OHB, but 
>>it's unclear to me how the endpoint would process those.  If the 
>>receiving endpoint sent an offer indicating it wanted to use extension 
>>"foo" with ID=6 and the sender of the particular RTP packet sent an 
>>offer for "foo" with an ID=5, then the receiver is not going be in 
>>agreement with the ID mapping of the sender.
>>
>>to the OHB.  It would then look for the "extension remapping 
>>extension" that would tell the receiver (in my example above) that 
>>"ID=6 is remapped to ID=5 before the OHB".  So, while the receiver had 
>>assumed ID=6 would be "foo", it would look before the OHB for ID=5.  
>>In effect, this is creating a way to get around that statement in RFC 
>>5285 that disallows remapping.
>>
>>>  So let me just confirm one thing with both of you (Paul & Sergio) 
>>>... you understand that the current design supports both E2E and HbH 
>>>header extensions and which way a given extension is handed is 
>>>currently determined by specification of the system not negotiated 
>>>over SDP?
>>>
>>>>  Sergio, you want E2E extensions?  Seems like it's going to be 
>>>>rather complicated to support with the current design.
>>>>
>>>>  Paul
>>>>
>>>>>>  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.
>>>>>>
>>>>>
>>>>>
>>>>>  If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and 
>>>>>ID of 1 and the conferences wants to use 22 because that is what 
>>>>>other endpoints are using, the conference server simply rejects 
>>>>>that in the answer then does and reoffers that with an ID of 22.
>>>>>

---

From: Roni Even <[email-masked]>
Date: Wed, 17 May 2017 05:23:51 +0000

Hi,
Note that one byte RTP header extensions can have IDs 1-14 so point 3 may be a problem if only one-byte is supported. Note that you cannot re-use IDs. The ID space management will be more complicated in a bundle case. We are discussing the IDs for bundle on avt mailing list
I agree with Paul and think that rewriting IDs by the MD will be the right way.

As for dropping RTP header extensions, the 5285-bis draft says  "intermediaries aware of the RTP  header extensions are advised to be cautious when removing or  generating RTP header extensions see section 4.7 of [RFC7667]."

Roni

> -----Original Message-----
> From: Perc [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: יום ג 16 מאי 2017 22:18
> To: Paul Jones
> Cc: Sergio Garcia Murillo; [email-masked]
> 2) for any extensions in the offer that are E2E, if they are not needed for this
> conferences, the MD can simply reject them in the SDP offer/answer and
> there will be no E2E extensions.
> 
> > If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and ID of 1 and
> the conferences wants to use 22 because that is what other endpoints are
> using, the conference server simply rejects that in the answer then does a
> reoffers with an ID of 22.
> 
> 
> Note that point 2 is very close to what  Sergio is arguing for here ...  one thing
> he might do in his implementation is simply make sure that if and endpoint
> attempts to negotiate an extension other than the ones his MD supports,
> make the MD rejects that extension. At that point his MD will not need to
> deal with any E2E stuff and there is not ordering.
> 
> Some systems that support extension might want to do 1 while others might
> want to do 3. Some systems might want to reject every extension other than
> client-to-mixer audio levels.
> 
> specs as they current exist will allow us to do that, but feel free to correct me
> if I'm wrong.
> >
> >   A session update MAY add or remove extension(s). Identifiers values in
> the valid range MUST NOT be altered (remapped).
> >
> for the same or overlapping extensions.  The extensions (including encrypted
> extensions) can be preserved before the OHB, but it's unclear to me how the
> endpoint would process those.  If the receiving endpoint sent an offer
> indicating it wanted to use extension "foo" with ID=6 and the sender of the
> particular RTP packet sent an offer for "foo" with an ID=5, then the receiver is
> not going be in agreement with the ID mapping of the sender.
> >
> > A solution could be to introduce an "extension remapping extension".  For
> example, the receiver would skip over all extensions until it gets to the OHB.
> It would then look for the "extension remapping extension" that would tell
> the receiver (in my example above) that "ID=6 is remapped to ID=5 before
> the OHB".  So, while the receiver had assumed ID=6 would be "foo", it would
> look before the OHB for ID=5.  In effect, this is creating a way to get around
> that statement in RFC 5285 that disallows remapping.
> >
> > AFAIK, we don't have language like that in any document and I don't think
> the MD is otherwise able to force all endpoints to use a common mapping.
> >
> > Paul
> >
> >> So let me just confirm one thing with both of you (Paul & Sergio) ... you
> understand that the current design supports both E2E and HbH header
> MDD can re-write header extensions values or remove them as it sees fit.
> >>>
> specifies the ID mapping. Multiple endpoints in a conference might indicate
> any number of didn't ID values for the same extension.
> >>>>>
> >>>>
> >>>>
> >>>> If Alice's UA offers urn:ietf:params:rtp-hdrext:encrypt with and ID of 1
> and the conferences wants to use 22 because that is what other endpoints
> are using, the conference server simply rejects that in the answer then does
> and reoffers that with an ID of 22.
> >>>>
> bridge would like to tell ALice's UA if this should be protected E2E or not. I'll
> send a separate email on that.
> >>>>
> >>>>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 17 May 2017 09:35:28 +0200

> As for dropping RTP header extensions, the 5285-bis draft says  "intermediaries aware of the RTP  header extensions are advised to be cautious when removing or  generating RTP header extensions see…
Note that an MD or any intermediary can't drop any E2E RTP header 
extension present in an rtp packet as it will break the inner crypto and 
will prevent the final endpoint to be able to decrypt it.

BR
Ser

---

From: Roni Even <[email-masked]>
Date: Wed, 17 May 2017 08:49:09 +0000

Ser,
Cullen in point 2 was proposing to signal that the extensions are not supported even though they can support it, so my comment was about being cautious in this case, it may break application logic. 
Roni

> From: Sergio Garcia Murillo [mailto:[email-masked]]
> Sent: יום ד 17 מאי 2017 10:35
> To: Roni Even; Cullen Jennings; Paul Jones
> Cc: [email-masked]
> > As for dropping RTP header extensions, the 5285-bis draft says
> "intermediaries aware of the RTP  header extensions are advised to be
> cautious when removing or  generating RTP header extensions see section
> 4.7 of [RFC7667]."
> >
> >
> extension present in an rtp packet as it will break the inner crypto and will
> prevent the final endpoint to be able to decrypt it.
> 
> BR
> Ser

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 17 May 2017 14:06:41 +0000

Roni,

I assume it's illegal to send a new offer during the call to remap IDs. 
Am I correct?  (I note here you said "you cannot re-use IDs", and I 
assume that would be considered re-use.)

Would it be reasonable to require that all E2E header extensions 
advertised using IDs values in the range 4096-4351, thus allowing the 
MDD to specify those values?

Paul

------ Original Message ------
From: "Roni Even" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>; "Paul Jones" 
<[email-masked]>
Cc: "Sergio Garcia Murillo" <[email-masked]>; 
"[email-masked]" <[email-masked]>
Sent: 5/17/2017 1:23:51 AM
Subject: RE: [Perc] Drop support for E2E RTP header extensions

>Hi,
>Note that one byte RTP header extensions can have IDs 1-14 so point 3 
>may be a problem if only one-byte is supported. Note that you cannot 
>re-use IDs. The ID space management will be more complicated in a 
>bundle case. We are discussing the IDs for bundle on avt mailing list
>>  I think you are wrong but let me know what parts of this you don't 
>>think work
>>  and we can work through it.
>>
>>  So lets split up a bunch of different ways a conference systems that 
>>uses the
>>  PERC stuff can do this.
>>
>>  3) for both HbH and E2E exertions, to repeat my prev email on this 
>>thread
>>  from May 13,
>>of 1 and
>>might
>>the
>>cannot
>>encrypted
>>think
>>... you
>>  >> Yes we could change any of that but I just want to make sure we 
>>are all on
>>  the same page of where we are now
>>  >>
>>  >>
>>  >>
>>  >>> On May 13, 2017, at 2:08 PM, Paul E. Jones 
>><[email-masked]>
>>  wrote:
>>  >>>
>>  >>> Cullen,
>>  >>>
>>rather
>>  >>>>> On May 12, 2017, at 12:10 AM, Paul E. Jones 
>><[email-masked]>
>>  wrote:
>>  >>>>>
>>offerer
>>indicate
>>  >>>> Just so we are all clear on how this would work ... sorry for 
>>the
>>  repetition ....
>>  >>>>
>>  >>>>
>>ID of 1
>>conference

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 17 May 2017 20:15:26 +0000

Folks,

I had a side discussion with Cullen on (3) to better understand what he 
meant.  I misunderstood his proposal, but now I think I understand and I 
think it would work.

As I now understand, a calling device could send an offer with IDs 
proposed, and the media distributor would return an answer removing any 
IDs that are values that are not what the media distributor wants to use 
(this is what Cullen meant by "reject" and I interpreted that to mean 
reject the entire offer itself).  The media distributor could then send 
a new offer and advertise the header extension values it wants to use.  
I don't think that would violate the spec in terms of remapping 
identifiers.

Another approach might be to only offer ID values in the range 
4096-4351, thus allowing the media distributor to return an answer with 
identifiers assigned.

So, there are a couple of ways to do this that I can see now.

Paul

------ Original Message ------
From: "Paul E. Jones" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>
Cc: "Sergio Garcia Murillo" <[email-masked]>; 
[email-masked]
Sent: 5/16/2017 3:51:27 PM
Subject: Re: [Perc] Drop support for E2E RTP header extensions

>don't want you to use ID=1 for 'foo'.  I want you to use ID=4 for 
>that."  Basically, the media distributor would need to reject the offer 
>and return an ID map for what it wants to see used.  How do we prevent 
>cascaded conference are in agreement on the set of values.  Perhaps 
>that is doable if there we assume only one vendor's media distributors 
>will be present in a conference.
>
>Paul
>
>>think work and we can work through it.
>>
>>uses the PERC stuff can do this.
>>
>>2) for any extensions in the offer that are E2E, if they are not 
>>needed for this conferences, the MD can simply reject them in the SDP 
>>thread from May 13,
>>Note that point 2 is very close to what  Sergio is arguing for here 
>>...  one thing he might do in his implementation is simply make sure 
>>that if and endpoint attempts to negotiate an extension other than the 
>>ones his MD supports, make the MD rejects that extension. At that 
>>point his MD will not need to deal with any E2E stuff and there is not 
>>ordering.
>>
>>>    A session update MAY add or remove extension(s). Identifiers 
>>>values in the valid range MUST NOT be altered (remapped).
>>>
>>>cannot change that mapping.   A dozen endpoints can offer different 
>>>ID mappings for the same or overlapping extensions.  The extensions 
>>>receiving endpoint sent an offer indicating it wanted to use 
>>>extension "foo" with ID=6 and the sender of the particular RTP packet 
>>>sent an offer for "foo" with an ID=5, then the receiver is not going 
>>>be in agreement with the ID mapping of the sender.
>>>
>>>  For example, the receiver would skip over all extensions until it 
>>>gets to the OHB.  It would then look for the "extension remapping 
>>>"ID=6 is remapped to ID=5 before the OHB".  So, while the receiver 
>>>had assumed ID=6 would be "foo", it would look before the OHB for 
>>>ID=5.  In effect, this is creating a way to get around that statement 
>>>in RFC 5285 that disallows remapping.
>>>
>>>>>>><[email-masked]> wrote:
>>>>>>>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 May 2017 10:20:48 -1000

> On May 17, 2017, at 10:15 AM, Paul E. Jones <[email-masked]> wrote:
> 
> 
> As I now understand, a calling device could send an offer with IDs proposed, and the media distributor would return an answer removing any IDs that are values that are not what the media distributor wants to use (this is what Cullen meant by "reject" and I interpreted that to mean reject the entire offer itself).  The media distributor could then send a new offer and advertise the header extension values it wants to use.  I don't think that would violate the spec in terms of remapping identifiers.
> 
> Another approach might be to only offer ID values in the range 4096-4351, thus allowing the media distributor to return an answer with identifiers assigned.

I had not thought about using the exclusive negotiation stuff. I like that it would work in a single Offer/Answer round instead of needing two.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 17 May 2017 17:14:29 -0500

That still doesn't answer my question (which Paul you also raised).

What happens if the offerer insists on using their own ID (potentially
because they are a PERC MDD themselves).

Emil

On Wed, May 17, 2017 at 3:15 PM, Paul E. Jones <[email-masked]> wrote:
> As I now understand, a calling device could send an offer with IDs proposed,
> and the media distributor would return an answer removing any IDs that are
> values that are not what the media distributor wants to use (this is what
> Cullen meant by "reject" and I interpreted that to mean reject the entire
> offer itself).  The media distributor could then send a new offer and
> advertise the header extension values it wants to use.  I don't think that
> would violate the spec in terms of remapping identifiers.
>
> Another approach might be to only offer ID values in the range 4096-4351,
> thus allowing the media distributor to return an answer with identifiers
> assigned.
>
> Cc: "Sergio Garcia Murillo" <[email-masked]>; [email-masked]
>> confusion.  The rejection would have to be detailed enough to say "I don't
>> want you to use ID=1 for 'foo'.  I want you to use ID=4 for that."
>> Basically, the media distributor would need to reject the offer and return
>> an ID map for what it wants to see used.  How do we prevent another offer
>> from simply offering a different ID map that is not acceptable?
>>
>> cascaded conference are in agreement on the set of values.  Perhaps that is
>> doable if there we assume only one vendor's media distributors will be
>> present in a conference.
>>
>> Paul
>>
>>> for this conferences, the MD can simply reject them in the SDP offer/answer
>>> and there will be no E2E extensions.
>>>
>>>> 1 and the conferences wants to use 22 because that is what other endpoints
>>>> a reoffers with an ID of 22.
>>>
>>>
>>>
>>> one thing he might do in his implementation is simply make sure that if and
>>> endpoint attempts to negotiate an extension other than the ones his MD
>>> supports, make the MD rejects that extension. At that point his MD will not
>>> need to deal with any E2E stuff and there is not ordering.
>>>
>>>> change that mapping.   A dozen endpoints can offer different ID mappings for
>>>> the same or overlapping extensions.  The extensions (including encrypted
>>>> particular RTP packet sent an offer for "foo" with an ID=5, then the
>>>> receiver is not going be in agreement with the ID mapping of the sender.
>>>>
>>>> For example, the receiver would skip over all extensions until it gets to
>>>> the OHB.  It would then look for the "extension remapping extension" that
>>>> would tell the receiver (in my example above) that "ID=6 is remapped to ID=5
>>>> before the OHB".  So, while the receiver had assumed ID=6 would be "foo", it
>>>> would look before the OHB for ID=5.  In effect, this is creating a way to
>>>> get around that statement in RFC 5285 that disallows remapping.
>>>>
>>>>> extensions and which way a given extension is handed is currently determined
>>>>> by specification of the system not negotiated over SDP?
>>>>>
>>>>>>> endpoints are using, the conference server simply rejects that in the answer
>>>>>>> then does and reoffers that with an ID of 22.
>>>>>>>
>>>>>>> conference bridge would like to tell ALice's UA if this should be protected
>>>>>>> E2E or not. I'll send a separate email on that.
>>>>>>>
>>>>>>>

-- 
https://jitsi.org

---

From: Roni Even <[email-masked]>
Date: Thu, 18 May 2017 04:56:32 +0000

Hi Paul,
Inline 
Roni

> From: Perc [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: יום ד 17 מאי 2017 23:15
> To: Cullen Jennings
> advertise the header extension values it wants to use.
> I don't think that would violate the spec in terms of remapping identifiers.
[Roni Even] My concern here is with the small number of one byte ID (1-14) , we may run out of IDs.
> thus allowing the media distributor to return an answer with identifiers
[Roni Even] This is the better way to address it.
> >>>>are all on the same page of where we are now
> >>>>
> >>>>
> >>>>
> >>>>>  I say we should NOT support E2E extensions.  Make them HBH and
> >>>>>the MDD can re-write header extensions values or remove them as it
> >>>>>sees fit.
> >>>>>
> >>>>>>the repetition ....

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2017 18:26:29 -0600

> On May 17, 2017, at 4:14 PM, Emil Ivov <[email-masked]> wrote:
> 

They can't join the conferences.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 23 May 2017 08:20:34 -0500

> They can't join the conferences.

How does that work exactly? Each party has a total number of retries
and once it has tried to amend the extension id for that many times,
then it gives up?

Let's file that in the April 1st category :)

On a more serious note, why don't we look at it this way: there is
already E2E protected content in PERC. It's the payload. If anyone
needs E2E protected information, they can put it there.

It may or may not work for some use cases but we have no way of
knowing since we don't have any use cases to go on. All the more
reason to forget about this and move on.

Emil

-- 
https://jitsi.org