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

[David Singer <[e-mail]>]

> 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.