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

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" <fluffy@iii.ca>
To: "Paul Jones" <paulej@packetizer.com>
Cc: "Sergio Garcia Murillo" <sergio.garcia.murillo@gmail.com>; 
perc@ietf.org
Sent: 5/16/2017 3:17:46 PM
Subject: Re: [Perc] Drop support for E2E RTP header extensions

>
>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 <paulej@packetizer.com> 
>>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.
>>
>>  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
>>
>>  _______________________________________________
>>  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