Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03

["Roni Even" <[e-mail]>]

Hi Dave,
Are you talking about this sentence in section 5
"In addition, as noted above,   the IDs used MUST be unique for each stream type for a given media,   or for the session for session-level declarations."
Roni
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, October 26, 2016 1:54 PM
> To: Roni Even
> Cc: Magnus Westerlund; [e-mail]; IETF
> AVTCore WG
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
> 
> 
> > On Oct 26, 2016, at 16:15 , Roni Even <[e-mail]> wrote:
> >
> > Hi,
> > My comment was that the extmap attribute has a value which is the ID
> > in the RTP header extension. So even though you can have in theory
> > inside the RTP streams two RTP header extension with the same ID
> > (1-14) carrying different extensions (which you could not do before
> > allowing one byte and two bytes in the same RTP stream), this is not
> > possible because of the extmap which MUST have unique ID in each RTP
> > session (even for bundle where you may have two bundled m-lines each
> > with its own extmap attribute )
> 
> you could never do this.  the number space for the forms was always a single
> space, as documented by the extmap attribute.
> 
> > Roni
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]]
> >> Sent: Wednesday, October 26, 2016 12:20 PM
> >> To: Roni Even
> >> Cc: Magnus Westerlund; [e-mail]; IETF
> >> AVTCore WG
> >> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
> >>
> >>
> >>> On Oct 26, 2016, at 0:20 , Roni Even <[e-mail]> wrote:
> >>>
> >>> Hi guys,
> >>> I will try to clarify but now I think that introducing the mix one
> >>> byte two
> >> byte will require some text that will say that the IDs or the values
> >> in the extmap need to be unique , to not allow the negotiation of one
> >> byte and two bytes with the same ID (1-14) in the same RTP stream.
> >>
> >> don’t understand you.  One uses two-byte if either (a) the ID is too
> >> big or (b) the payload is too big, for the one-byte.
> >>
> >>>
> >>> Does this sound OK?
> >>>
> >>> Roni
> >>>
> >>>> -----Original Message-----
> >>>> From: Magnus Westerlund [mailto:[e-mail]]
> >>>> Sent: Tuesday, October 25, 2016 6:30 PM
> >>>> To: David Singer; Roni Even
> >>>> Cc: [e-mail]; IETF AVTCore WG
> >>>> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
> >>>>
> >>>> Den 2016-10-25 kl. 17:08, skrev David Singer:
> >>>>>
> >>>>>> On Oct 25, 2016, at 20:31 , Roni Even <[e-mail]>
> >> wrote:
> >>>>>>
> >>>>>> Hi Magnus and Dave,
> >>>>>> My question here is that if you have the extmap attribute in SDP
> >>>>>> it means that you support RFC5285 so does it imply support for
> >>>>>> two bytes
> >>>> extension?
> >>>>>> On the other hand the document mandates the support of one byte
> >>>>>> by the receivers and does not say anything about support of two
> bytes.
> >>>>>>
> >>>>>> So it looks to me that like what Magnus said about the
> >>>>>> negotiation phase that only the a=extmap-allow-mixed by both
> >>>>>> sides implies full support of two bytes extensions may be correct?
> >>>>>>
> >>>>>> Is this your view also?
> >>>>>>
> >>>>>> Do you think that we should emphasis this in the text?
> >>>>>
> >>>>> yes, agreeing to mixed means you must support two-byte; otherwise,
> >>>>> it’s optional (or at least not mandated)
> >>>>
> >>>> It would have been nice to be able to arrive at two-byte support
> >>>> based on the extmap. So, clearly attempt to negotiate ID > 15 but
> >>>> not in 40xx range implies support for two-byte. But, negotiation of
> >>>> IDs lower than
> >>>> 15 does not say anything about two byte. I think that is my conclusion.
> >>>>
> >>>> I am sorry that I don't have time to provide a text proposal.
> >>>> Editor and authors it would be good if you at least consider if you
> >>>> see anything that should be clarified in this regards.
> >>>>
> >>>> Cheers
> >>>>
> >>>> Magnus
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Roni
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Magnus Westerlund
> >> [mailto:[e-mail]]
> >>>>>>> Sent: Tuesday, October 18, 2016 4:52 PM
> >>>>>>> To: David Singer
> >>>>>>> Cc: Roni Even; [e-mail]; IETF
> >>>>>>> AVTCore WG
> >>>>>>> Subject: Re: [AVTCORE] Comments on
> >>>>>>> draft-ietf-avtcore-rfc5285bis-03
> >>>>>>>
> >>>>>>> Den 2016-10-18 kl. 12:07, skrev David Singer:
> >>>>>>>>
> >>>>>>>>> On Oct 18, 2016, at 16:53 , Magnus Westerlund
> >>>>>>>>> <[e-mail]> wrote:
> >>>>>>>>>
> >>>>>>>>> I think there is a negotiation mechanism, in that if one
> >>>>>>>>> include extmap mappings for values above 15, then you indicate
> >>>>>>>>> that you support the two-byte format, and if you accept you
> >>>>>>>>> can clearly indicate this. Maybe this should be made more
> >>>>>>>>> explicit, as a method of determining the operations mode. To
> >>>>>>>>> me we do now
> >> end
> >>>> up
> >>>>>>>>> with four different cases:
> >>>>>>>>>
> >>>>>>>>> A. One-byte only: only ID's in range 1-14. The state of
> >>>>>>>>> a=extmap-allow-mixed has no meaning, only indication if one
> >>>>>>>>> want to renegotiate.
> >>>>>>>>>
> >>>>>>>>> B. two-byte only: only ID's above 15. The state of
> >>>>>>>>> a=extmap-allow-mixed has no meaning, only indication if one
> >>>>>>>>> want to renegotiate.
> >>>>>>>>
> >>>>>>>> sorry, I don’t get this.  Two-byte headers get you full-byte
> >>>>>>>> length fields and thus longer payloads. You could use these
> >>>>>>>> with small local IDs.  Why say you have to use IDs outside 1-14???
> >>>>>>>
> >>>>>>> Yes, you are correct. I made a mistake in my thoughts, and
> >>>>>>> forgot about these possibilities. I would like to correct myself
> >>>>>>> to say that only at
> >>>>>> least one
> >>>>>>> ID above 15 implies and no a=extmap-allow-mixed that you can use
> >>>>>>> two- byte headers and may do that for some RTP streams.
> >>>>>>>
> >>>>>>> But the other implication of your comment is that one can't draw
> >>>>>>> the conclusion that IDs only in 1-14 range implies only one-byte
> >> headers.
> >>>>>>>
> >>>>>>> So to make this more complete, the additional criteria that can
> >>>>>>> be used to determine at signaling time if one will use one or
> >>>>>>> two-byte headers is the inclusion and acceptance of an RTP
> >>>>>>> header extension that requires a length of data that is more
> >>>>>>> than 16 bytes. But, for extension that doesn't have
> >>>>>> that
> >>>>>>> given, like the CNAME that could be of quite different lengths
> >>>>>>> both above and below the range one can't make that
> determination.
> >>>>>>>
> >>>>>>> I was trying to arrive here that one could determine support for
> >>>>>>> two-byte headers based on what was signalled, even without the
> >>>>>>> a=extmap-allow- mixed SDP attribute.
> >>>>>>>
> >>>>>>> So a=extmap-allow-mixed provides not only indication that you
> >>>>>>> can switch, but also that one supports both one and two-byte
> headers.
> >>>>>>>
> >>>>>>> But for the legacy case, one could negotiate using low IDs
> >>>>>>> (1-14) range
> >>>>>> only,
> >>>>>>> and then realize at transmission start time that one have to use
> >>>>>>> the
> >>>>>> two-byte
> >>>>>>> headers. Then one could end up in an interoperability failure as
> >>>>>>> the old receiver is not required to support the two-bytes header.
> >>>>>>>
> >>>>>>> So based on the above implications, one could write text that
> >>>>>>> gives recommendations that for any signaling case where one
> >>>>>>> knows that one will have to use two-byte to assign that
> >>>>>>> extension an ID above 15 to indicate
> >>>>>> this.
> >>>>>>> But, I guess for the one where one don't know one simply have to
> >>>>>>> hope that it works, and indicate that this issue is resolved if
> >>>>>>> one follows this specification and indicates a=extmap-allow-mixed.
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>> Magnus Westerlund
> >>>>>>>
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> -- Services, Media and Network features, Ericsson Research
> >>>>>>> EAB/TXM
> >>>>>>> ----------------------------------------------------------------------
> >>>>>>> Ericsson AB                 | Phone  [phone]
> >>>>>>> Färögatan 6                 | Mobile [phone]
> >>>>>>> SE-164 80 Stockholm, Sweden | mailto:
> >>>> [e-mail]
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> --
> >>>>>>
> >>>>>
> >>>>> David Singer
> >>>>> Manager, Software Standards, Apple Inc.
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Magnus Westerlund
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> - Services, Media and Network features, Ericsson Research EAB/TXM
> >>>> ----------------------------------------------------------------------
> >>>> Ericsson AB                 | Phone  [phone]
> >>>> Färögatan 6                 | Mobile [phone]
> >>>> SE-164 80 Stockholm, Sweden | mailto:
> >> [e-mail]
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>
> >>
> >> David Singer
> >> Manager, Software Standards, Apple Inc.
> >
> 
> David Singer
> Manager, Software Standards, Apple Inc.