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

Magnus Westerlund <> Tue, 18 October 2016 08:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 568CE1299C7; Tue, 18 Oct 2016 01:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4HYQroDKtD0K; Tue, 18 Oct 2016 01:54:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1553712956A; Tue, 18 Oct 2016 01:54:07 -0700 (PDT)
X-AuditID: c1b4fb30-f60a598000000cb2-aa-5805e32d0b1a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E6.1D.03250.D23E5085; Tue, 18 Oct 2016 10:54:06 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Tue, 18 Oct 2016 10:53:09 +0200
To: Roni Even <>, <>, 'IETF AVTCore WG' <>
References: <> <0eb001d2289a$ccf86070$66e92150$>
From: Magnus Westerlund <>
Message-ID: <>
Date: Tue, 18 Oct 2016 10:53:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <0eb001d2289a$ccf86070$66e92150$>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM2K7iq7eY9YIg44mPouXPSvZLXa8fsVi 8bed2YHZY+esu+weS5b8ZApgiuKySUnNySxLLdK3S+DKOLG+naXgcHjF8amfWRoYF7h2MXJy SAiYSCx+fYa1i5GLQ0hgPaNEY+clNghnOaPExc537CBVwgLOEr9nTwKzRQRKJf63dDCD2EIC uRLL+84wgthsAhYSN380soHYvAL2EqtuXQOzWQRUJbZOmM4EYosKxEhcf/YIqkZQ4uTMJywg NidQ78sVb4Dmc3AwA/U+2FoGEmYWkJdo3jobapW2RENTB+sERv5ZSLpnIXTMQtKxgJF5FaNo cWpxUm66kZFealFmcnFxfp5eXmrJJkZgEB7c8ttgB+PL546HGAU4GJV4eBNuskQIsSaWFVfm HmKU4GBWEuFluccaIcSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgs EwenVANj+dzdOv8fuFonGGzl4CidKtiteWthxpn8JX9YmDpbhe5PrVQ/s3R7RP9W0QXvVn1f r/TY5crc9VPTkio5PWK/HY+MzmXnPaod58a9d/5Zx7j63/oRT09PNYrbk21QvT51dboph4XP jmt6Wla6Uxe8XMM3oZy9omCjkmmb94d0hUfsId8rvAyUWIozEg21mIuKEwGVWYclPgIAAA==
Archived-At: <>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rfc5285bis-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Oct 2016 08:54:11 -0000


Some follow up, removing the settled things.

Den 2016-10-17 kl. 19:20, skrev Roni Even:
>> From: avt [] On Behalf Of Magnus Westerlund

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

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

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

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 

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.

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

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.

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

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.

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

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

>> 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.
> [Roni Even]  So you suggest I remove this text and write that the direction
> is following RFC3264 stream behavior? Is there a difference?

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

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

> [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?

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.

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

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?

>> 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.
> [Roni Even] Thanks for noticing, will do. Strange that it happened and even
> more that in
> it provides a link to the RFCs without the reference since in my xml file
> there is no reference just [rfc3611] and no <xref ...>

The HTML version of the document that 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 


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: