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

[David Singer <[e-mail]>]

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