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

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" <fluffy@iii.ca>
To: "Paul Jones" <paulej@packetizer.com>; "Sergio Garcia Murillo" 
<sergio.garcia.murillo@gmail.com>
Cc: perc@ietf.org
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?
>
>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 <paulej@packetizer.com> 
>>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
>>
>>  ------ Original Message ------
>>  From: "Cullen Jennings" <fluffy@iii.ca>
>>  To: "Paul Jones" <paulej@packetizer.com>
>>  Cc: perc@ietf.org
>>  Sent: 5/13/2017 10:33:35 AM
>>  Subject: Re: [Perc] Drop support for E2E RTP header extensions
>>
>>>
>>>
>>>>  On May 12, 2017, at 12:10 AM, Paul E. Jones <paulej@packetizer.com> 
>>>>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.
>>>>
>>>
>>>
>>>  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.
>>>
>>>
>>>  _______________________________________________
>>>  Perc mailing list
>>>  Perc@ietf.org
>>>  https://www.ietf.org/mailman/listinfo/perc
>>
>>  _______________________________________________
>>  Perc mailing list
>>  Perc@ietf.org
>>  https://www.ietf.org/mailman/listinfo/perc
>
>_______________________________________________
>Perc mailing list
>Perc@ietf.org
>https://www.ietf.org/mailman/listinfo/perc