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

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

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" <[e-mail]>
To: "Cullen Jennings" <[e-mail]>; "Paul Jones" 
<[e-mail]>
Cc: "Sergio Garcia Murillo" <[e-mail]>; 
"[e-mail]" <[e-mail]>
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 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:[e-mail]] On Behalf Of Cullen 
>>Jennings
>>  Sent: יום ג 16 מאי 2017 22:18
>>  To: Paul Jones
>>  Cc: Sergio Garcia Murillo; [e-mail]
>>  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