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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Oct 2016 16:46:52 +0200

Hi,

I did a review to see if this was ready for WG last call. I have found 
some issues that needs to be addressed prior to the WG last call.

1. Abstract:
The abstract is not explicit that this document obsoletes RFC5285.

2. Section 1:
"   This document removes a limitation from RFC5285 that did not allow
    sending both one byte and two bytes header extensions in the same RTP
    stream".

This needs to say explicitly that is obsoletes RFC5285. When it comes to 
the changes, this is clearly the major one, but it is not the only one. 
I think the document should have a more explicit list of the changes 
compared to RFC5285. I would actually recommend that a new section is 
created that discusses the changes related to RFC 5285. This will not be 
super long, but I think when you summarize the changes there are 
actually a couple of paragraphs.

3. Section 4.1.1:

some general considerations for getting the header extensions
    delivered to the receiver:

Should the "some" not be "Some"?

4. Section 4.1.2:

Since it is expected that (a) the number of extensions in
    any given RTP session is small and (b) the extensions themselves are
    small, the one-byte header form is preferred and MUST be supported by
    all receivers.

I know this would be an updated requirement, but shouldn't we clarify 
the implementation requirements to actually include both one and two 
byte headers for receivers, if following this version of the 
specification? The usage of switching is still only after having 
successfully negotiated support for it.

5. Section 4.1.2:

One-byte and two-byte headers MUST NOT be mixed in a
    single RTP packet.

As this is not possible as the one and two byte headers for the RTP 
header extension are different and only one of them can be present in a 
given RTP packet. I fear that this sentence causes confusion and are 
interpreted such that the extensions with IDs assigned in 1-14 range 
can't be used in two-byte header when such signaled. I think this 
sentence to be rewritten so that it says: Each RTP packet with an RTP 
header extension following this specification will indicate if it 
contains one or two byte header extensions through the use of the 
"defined by profile" field. Only the extension element types that match 
the header extension format, i.e. one- or two-byte, MUST be used in that 
RTP packet.

6. Section 4:

I think this section, possibly in 4.3 needs to be more explicit that 
header extensions that are configured using value 1-14 and thus supports 
the one-byte header format, can equally be used in the two-byte header. 
And in this case they use the same code-point values. I.e. there is not 
two different ID spaces (0-256, 15 reserved, and 0 is padding), only one.

7. Section 5:

and <direction> is one of
    "sendonly", "recvonly", "sendrecv", or "inactive" (without the
    quotes).

My interpretation of the above is that this applies in relation to the 
endpoint being configured. However, that could be made more clear as 
this is basically the declarative rules.

8. Section 6:
    When doing SDP Offer/Answer [RFC3264] an offering client that wishes
    to use both one and two bytes extensions MUST include the attribute
    "a= extmap-allow-mixed " in the SDP offer.

The above text fails to define that it applies to using both formats 
with an individual RTP stream. To my understanding if one would fail to 
negotiate this SDP attribute, but can negotiate both ID in the range 
1-14 and in 16-256 then one can on an RTP stream basis select which 
format one will persistently use for that SSRC. I wonder if that should 
be made clear also?

9. Section 7:

A "sendonly" direction
    indicates an ability to send; a "recvonly" direction indicates a
    desire to receive; a "sendrecv" direction indicates both.  An
    "inactive" direction indicates neither, but later re-negotiation MAY
    make an extension active.

I think this text should be removed and replaced with a pointer to the 
definitions in RFC 3264 as it fails to take into account how the 
directions are interpreted in relation to ones role for creating or 
receiving the SDP message.

10. Section 9:

I think the security consideration could point out that there exist 
alternative protection mechanisms as discussed in RFC 7201 that also can 
provide confidentiality for RTP header extensions.

11. Section 9:

This section is actually quite bad at raising the issues with the 
mechanisms it creates. First of all it is important that the signaling 
is protecting the negotiation to prevent blocking use of the extensions, 
or in some case even enabling extensions that has known vulnerabilities. 
Thus indicating need for integrity and source authentication.

On the RTP plane the header extension mechanism is vulnerable to denial 
of service attacks through modification of the RTP header extension 
structure. Possible force an alternative interpretation of data as well 
as data modifications.

12. Section 10.1:

       2.  that the extension complies with the requirements of RTP and
           this specification, for extensions (notably, that the stream
           is still decodable if the extension is ignored or not
           recognized);

I believe there is need to tweak this bullet.

13. Section 10.2:

I would recommend that you update this section to use the template for 
the information for the SDP attribute (as 10.3 uses), so that 10.2 and 
10.3 looks similar. I note that the registry for the existing attribute 
should actually be updated to point at the new RFC when completed. This 
should be indicated also.

14. Section 12.2:
This section lacks the following RFCs: 3611, 4585, 4588, 5109. All are 
mentioned in the text, but all lacks a reference.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Mon, 17 Oct 2016 20:20:46 +0300

HI Magnus,
Thanks, I will update the document, 
As for the comments, see inline

> -----Original Message-----
> From: avt [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, October 17, 2016 5:47 PM
> To: [email-masked]; IETF AVTCore WG
> Subject: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
> 
> Hi,
> 
some
> issues that needs to be addressed prior to the WG last call.
> 
> 1. Abstract:
[Roni Even] OK
> This needs to say explicitly that is obsoletes RFC5285. 
[Roni Even] OK
When it comes to the
> changes, this is clearly the major one, but it is not the only one.
super
> long, but I think when you summarize the changes there are actually a
couple
> of paragraphs.
[Roni Even] I think that this is the major change and the rest are
clarifications, but it may be good to have a section describing the changes
from RFC5285  for clarity.
> Should the "some" not be "Some"?
[Roni Even] OK
> I know this would be an updated requirement, but shouldn't we clarify the
> implementation requirements to actually include both one and two byte
> headers for receivers, if following this version of the specification? The
> usage of switching is still only after having successfully negotiated
support
> for it.
[Roni Even] I think that even in rfc5285 the support for two bytes is only
supported if the extmap is defined since before there was only one byte and
no negotiation mechanism. This update adds the mixing attribute in an RTP
stream. The receiver support for one byte with no signaling is the based on
pre RFC5285. So I am not sure that we need any more text. 
> As this is not possible as the one and two byte headers for the RTP header
> extension are different and only one of them can be present in a given RTP
> packet. I fear that this sentence causes confusion and are interpreted
such
> that the extensions with IDs assigned in 1-14 range can't be used in
two-byte
> header when such signaled. I think this sentence to be rewritten so that
it
> says: Each RTP packet with an RTP header extension following this
> specification will indicate if it contains one or two byte header
extensions
> through the use of the "defined by profile" field. Only the extension
element
> types that match the header extension format, i.e. one- or two-byte, MUST
> be used in that RTP packet.
[Roni Even] I will update the text as you suggested
> I think this section, possibly in 4.3 needs to be more explicit that
header
> extensions that are configured using value 1-14 and thus supports the one-
> byte header format, can equally be used in the two-byte header.
two
> different ID spaces (0-256, 15 reserved, and 0 is padding), only one.
[Roni Even]  This is the text in 4.3 "The 8-bit ID is the local identifier
of this element in the range
   1-255 inclusive.  In the signaling section, the range 1-256 is  referred
to as the valid range, with the values 1-255 referring to
   extension elements, and the value 256 referring to the 4-bit field
'appbits' (above)."
You want more clarification?

> My interpretation of the above is that this applies in relation to the
endpoint
> being configured. However, that could be made more clear as this is
basically
> the declarative rules.
[Roni Even] I am not sure what you mean here, this is also true for the
rfc3264 unicast stream support, the direction is from the offerer to the
answerer
> The above text fails to define that it applies to using both formats with
an
> individual RTP stream. To my understanding if one would fail to negotiate
> this SDP attribute, but can negotiate both ID in the range
> 1-14 and in 16-256 then one can on an RTP stream basis select which format
> one will persistently use for that SSRC. I wonder if that should be made
clear
> also?
[Roni Even] the last sentence of section 6 has some of , will add that
either one or two bytes can be used based on the negotiation.
> definitions in RFC 3264 as it fails to take into account how the
directions are
> interpreted in relation to ones role for creating or receiving the SDP
> message.
[Roni Even]  So you suggest I remove this text and write that the direction
is following RFC3264 stream behavior? Is there a difference?
> I think the security consideration could point out that there exist
alternative
> protection mechanisms as discussed in RFC 7201 that also can provide
> confidentiality for RTP header extensions.
[Roni Even] OK
> This section is actually quite bad at raising the issues with the
mechanisms it
> creates. First of all it is important that the signaling is protecting the
> negotiation to prevent blocking use of the extensions, or in some case
even
> enabling extensions that has known vulnerabilities.
> On the RTP plane the header extension mechanism is vulnerable to denial of
> service attacks through modification of the RTP header extension
structure.
> Possible force an alternative interpretation of data as well as data
> modifications.
[Roni Even] the text is RFC5285 had 
" Therefore, it is inappropriate to place  information in header extensions
that cause security problems if  disclosed, unless the entire RTP packet is
protected by a lower-layer  security protocol providing both confidentiality
and integrity  capability."
You think we should have this also in the security section?
> I believe there is need to tweak this bullet.
[Roni Even] This is the text from RFC5285, I believe it says that when
reviewing an extension the expert must verify that lack of support will not
prevent the decoding of the RTP stream. Any suggestion for text here?
> 
> 13. Section 10.2:
> 
> I would recommend that you update this section to use the template for the
> information for the SDP attribute (as 10.3 uses), so that 10.2 and
should
> actually be updated to point at the new RFC when completed. This should be
> indicated also.
[Roni Even] OK, I think that 10.3 is the right  template
> mentioned in the text, but all lacks a reference.
[Roni Even] Thanks for noticing, will do. Strange that it happened and even
more that in https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-03
it provides a link to the RFCs without the reference since in my xml file
there is no reference just [rfc3611] and no <xref ...>

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Oct 2016 10:53:07 +0200

Hi,

Some follow up, removing the settled things.

> from RFC5285  for clarity.

There is actually one more significant change. We are softening the 
requirement that header extensions needs to be ignorable.

> pre RFC5285. So I am not sure that we need any more text.

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.

C. one or two-byte, but no switching between within a RTP stream: No 
a=extmap-allow-mixed attribute, but negotiated IDs both in 1-14 as well 
as above 15.

D. one and two-bytes with switching: a=extmap-allow-mixed and negotiated 
IDs both in 1-14 as well as above 15.

Maybe the above alternatives should be made explicit to ensure that 
implementers understand and consider all the alternatives.

> You want more clarification?

Yes, the above text does not make it clear that the lower values (1-14) 
can be used in the 4-bit ID field in the one-byte header format. Yes, 
one should arrive at this conclusion based on that there are no 
signalling for different number spaces, but I think there might be some 
point of being very clear on this.

> rfc3264 unicast stream support, the direction is from the offerer to the

If you read the definitions in RFC 3264 of the "sendonly" etc. they are 
defined in relation to an offer or an answer. That is not the case for 
the definitions in this document. And when one interpret these attribute 
in a declarative usage of SDP, then one should be clear if sendonly, 
means if this applies to the device being configured, or if is the 
configuration of the rest of the session. In usages of SDP in SAP or 
RTSP DESCRIBE this is relevant. Yes, this should be from perspective of 
the device being configured. So that recvonly means only for incoming 
streams, not anything it sends.

> either one or two bytes can be used based on the negotiation.

Yes, or maybe use the format for the options raised in issue 4 above.

> is following RFC3264 stream behavior? Is there a difference?

No, I don't think there is a difference, just more sloppy definitions.

> You think we should have this also in the security section?

So the issue it raises is still relevant, the remedy is wrong as there 
exist options to ensure this, either lower layer protections protecting 
the entire packet, like DTLS, or SRTP with RFC6904.

> prevent the decoding of the RTP stream. Any suggestion for text here?

So, based on the RTP header extensions recently defined or under 
definition, like RID and MID, they are not preventing RTP stack level 
processing, but in some cases failure to understand them prevents the 
application from working correctly. Even for middleboxes there exist a 
need to understand them to be able to route them correctly.

So the requirement was changed in Section 4.1 to say:

    To be specific, header extensions using this
    specification SHOULD be used for data that can safely be ignored by
    the recipient without affecting interoperability, there can be
    essential header extensions for interoperability and intermediaries
    SHOULD NOT remove such header extensions.

So my proposed text change is to remove the parenthesis.

I think the reviewer should be questioning the need for any header 
extension that modifies how the RTP stack processes the packet. The 
current situation is that we are going to have RTP header extension that 
are going to be critical for applications or at least certain 
functionalities in applications. I think we have to accept that, but we 
should I think ensure that the extensions are open and explicit in which 
way they may become required for interoperability or functionality. So 
the question is if we should rather add a requirement for documenting 
that need?

> there is no reference just [rfc3611] and no <xref ...>

The HTML version of the document that tools.ietf.org provides are 
processed from the text version, and any [RFCXXXX] with a link to 
RFCXXXX, even when there are no entry in the reference tables. This is 
so that this markup can be provided also for docs that doesn't have XML 
source.

Cheers

Magnus Westerlund

---

From: David Singer <[email-masked]>
Date: Tue, 18 Oct 2016 18:07:54 +0800

> On Oct 18, 2016, at 16:53 , Magnus Westerlund <[email-masked]> 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???

> 
> C. one or two-byte, but no switching between within a RTP stream: No a=extmap-allow-mixed attribute, but negotiated IDs both in 1-14 as well as above 15.
> 
> D. one and two-bytes with switching: a=extmap-allow-mixed and negotiated IDs both in 1-14 as well as above 15.
> 
> Maybe the above alternatives should be made explicit to ensure that implementers understand and consider all the alternatives.

David Singer
Manager, Software Standards, Apple Inc.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 18 Oct 2016 15:04:24 +0300

Hi,
I agree with Dave
Roni

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2016 1:08 PM
> To: Magnus Westerlund
> Cc: Roni Even; [email-masked]; IETF AVTCore WG
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
> 
> 
> 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.
> >
> 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???
> 
> 
> >
> a=extmap-allow-mixed attribute, but negotiated IDs both in 1-14 as well as
> above 15.
> >
> > D. one and two-bytes with switching: a=extmap-allow-mixed and
> negotiated IDs both in 1-14 as well as above 15.
> >

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Oct 2016 15:52:16 +0200

Den 2016-10-18 kl. 12:07, skrev David Singer:
>> 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:
>>
>> B. two-byte only: only ID's above 15. The state of
> 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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 24 Oct 2016 17:01:53 +0300

Hi Magnus,
So can you try to summarize what text you propose to add
Thanks
Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2016 4:52 PM
> To: David Singer
> >> of determining the operations mode. To me we do now end up with four
> >> different cases:
> >>
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.
> 
> 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.
> 
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.
> 
> 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
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 25 Oct 2016 18:01:15 +0300

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?

Roni

least one
that
only,
two-byte
this.

---

From: David Singer <[email-masked]>
Date: Tue, 25 Oct 2016 20:38:00 +0530

> On Oct 25, 2016, at 20:31 , Roni Even <[email-masked]> wrote:
> 
> Hi Magnus and Dave,

yes, agreeing to mixed means you must support two-byte; otherwise, it’s optional (or at least not mandated)

David Singer

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Oct 2016 17:29:41 +0200

> 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

-- 

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Tue, 25 Oct 2016 21:50:35 +0300

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.

Does this sound OK?

Roni

> Sent: Tuesday, October 25, 2016 6:30 PM
> To: David Singer; Roni Even
> Cc: [email-masked]; IETF AVTCore WG
> >> 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?
> >>
> 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
> authors it would be good if you at least consider if you see anything that
> should be clarified in this regards.
> 
> Cheers
> 
> Magnus
> 
> >
> >>
> >> Roni
> >>
> >>
> >>>>> 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=extmap-allow-mixed has no meaning, only indication if one want
> >>>>> to renegotiate.
> >>>>>
> >>>>> a=extmap-allow-mixed has no meaning, only indication if one want
> >>>>> to renegotiate.
> >>>>
> >>>> 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.
> >>>
> >>> 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.
> >>>
> >>> a=extmap-allow- mixed SDP attribute.
> >>>
> >>> headers. Then one could end up in an interoperability failure as the
> >>> old receiver is not required to support the two-bytes header.
> >>>
> >>> indicate
> >>> 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

---

From: David Singer <[email-masked]>
Date: Wed, 26 Oct 2016 14:49:54 +0530

> On Oct 26, 2016, at 0:20 , Roni Even <[email-masked]> wrote:
> 
> Hi guys,

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.

David Singer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 26 Oct 2016 13:45:01 +0300

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 )
Roni

> Sent: Wednesday, October 26, 2016 12:20 PM
> To: Roni Even
> Cc: Magnus Westerlund; [email-masked]; IETF
> AVTCore WG
> > 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
> >
> >> 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
> >> 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
> >>>>
> >>>>
> >>>>>> 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???
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>> hope that it works, and indicate that this issue is resolved if
> >> ---------------------------------------------------------------------
> >> - Services, Media and Network features, Ericsson Research EAB/TXM

---

From: David Singer <[email-masked]>
Date: Wed, 26 Oct 2016 16:23:44 +0530

> On Oct 26, 2016, at 16:15 , Roni Even <[email-masked]> wrote:
> 
> Hi,

you could never do this.  the number space for the forms was always a single space, as documented by the extmap attribute.

>>>> -

David Singer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 26 Oct 2016 14:05:11 +0300

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
> Sent: Wednesday, October 26, 2016 1:54 PM
> To: Roni Even
> > 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
> >
> >> 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
> >>>
> >>>>>> 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?
> >>>>>>
> >>>> 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
> >>>> 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
> >>>>>>
> >>>>>>
> >>>>>>>>> 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
> >>>>>>>>> a=extmap-allow-mixed has no meaning, only indication if one
> >>>>>>>>> want to renegotiate.
> >>>>>>>>>
> >>>>>>>>> a=extmap-allow-mixed has no meaning, only indication if one
> >>>>>>>>> want to renegotiate.
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>> 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
> >>>>>>> So a=extmap-allow-mixed provides not only indication that you
> >>>>>>> can switch, but also that one supports both one and two-byte
> headers.
> >>>>>>>
> >>>>>>> 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.
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> ----------------------------------------------------------------
> >>>>>>> --
> >>>>>>> --
> >>>>>>> --
> >>>>>>
> >>>>>
> >>>>> David Singer