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

[Emil Ivov <[e-mail]>]

That still doesn't answer my question (which Paul you also raised).

What happens if the offerer insists on using their own ID (potentially
because they are a PERC MDD themselves).

Emil

On Wed, May 17, 2017 at 3:15 PM, Paul E. Jones <[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> Perc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/perc



-- 
https://jitsi.org