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:perc-bounces@ietf.org] On Behalf Of Cullen Jennings
> Sent: יום ג 16 מאי 2017 22:18
> To: Paul Jones
> Cc: Sergio Garcia Murillo; perc@ietf.org
> 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