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

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

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" <[e-mail]>
To: "Cullen Jennings" <[e-mail]>
Cc: "Sergio Garcia Murillo" <[e-mail]>; 
[e-mail]
Sent: 5/16/2017 3:51:27 PM
Subject: 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" <[e-mail]>
>To: "Paul Jones" <[e-mail]>
>Cc: "Sergio Garcia Murillo" <[e-mail]>; 
>[e-mail]
>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 <[e-mail]> 
>>>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" <[e-mail]>
>>>  To: "Paul Jones" <[e-mail]>; "Sergio Garcia Murillo" 
>>><[e-mail]>
>>>  Cc: [e-mail]
>>>  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 <[e-mail]> 
>>>>>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" <[e-mail]>
>>>>>  To: "Paul Jones" <[e-mail]>
>>>>>  Cc: [e-mail]
>>>>>  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 
>>>>>>><[e-mail]> 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
>>>>>>  [e-mail]
>>>>>>  https://www.ietf.org/mailman/listinfo/perc
>>>>>
>>>>>  _______________________________________________
>>>>>  Perc mailing list
>>>>>  [e-mail]
>>>>>  https://www.ietf.org/mailman/listinfo/perc
>>>>
>>>>  _______________________________________________
>>>>  Perc mailing list
>>>>  [e-mail]
>>>>  https://www.ietf.org/mailman/listinfo/perc
>>>
>>>  _______________________________________________
>>>  Perc mailing list
>>>  [e-mail]
>>>  https://www.ietf.org/mailman/listinfo/perc
>>
>>_______________________________________________
>>Perc mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/perc