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

[Roni Even <[e-mail]>]

Hi Paul,
Inline 
Roni

> -----Original Message-----
> From: Perc [mailto:[e-mail]] On Behalf Of Paul E. Jones
> Sent: יום ד 17 מאי 2017 23:15
> To: Cullen Jennings
> Cc: Sergio Garcia Murillo; [e-mail]
> Subject: Re: [Perc] Drop support for E2E RTP header extensions
> 
> 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.
[Roni Even] My concern here is with the small number of one byte ID (1-14) , we may run out of IDs.
> 
> 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.
[Roni Even] This is the better way to address it.
> 
> 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
> 
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc