Re: [AVTCORE] WG Last Call for draft-ietf-avtcore-rfc5285-bis-05

Hi Colin,
Your proposed text is better than the current text to reflect the point that RTP header extension must not disrupt RTP interoperability but may disrupt higher level interoperability, still maybe it will be good to have some recommendation for the intermediaries to not discard RTP headers automatically. Using SHOULD NOT implies that there may be a reason for the intermediary to remove some of  the header extensions.
There is also some text about it in RFC7667 section 4.7( https://tools.ietf.org/html/rfc7667#section-4.7 ). In the RTP mixer case, I think that since the mixer generate new RTP and RTCP messages, if the RTP mixer is aware of the received RTP header extensions, it will be good if it can decide what to send in both the RTP and RTCP messages.  With regards to the text in RFC3550 “is designed so  that the header extension may be ignored by other interoperating  implementations that have not been extended”, RFC 5285 adds the end to end negotiation for the RTP header extensions supported by both ends so the assumption is that if there is an RTP header extension than it is understood by the RTP receiver (may even be an MCU or RTP SFM using the audio level client to mixer RTP header extension ).

How about adding to your text

“The use of header extensions to
   convey information that will, if missing, disrupt the behaviour of a
   higher layer application that builds on top of RTP is only acceptable
   if this doesn't affect interoperability at the RTP layer, still intermediaries aware of the RTP header extensions are advised to be cautious when removing or generating RTP header extensions see section 4.7 of [RFC7667]”

Roni

From: Colin Perkins <csp@csperkins.org<mailto:csp@csperkins.org>>
Date: Wed, Dec 21, 2016 at 7:06 PM
Subject: Re: [AVTCORE] WG Last Call for draft-ietf-avtcore-rfc5285-bis-05
To: Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>>
Cc: IETF AVTCore WG <avt@ietf.org<mailto:avt@ietf.org>>

> On 9 Dec 2016, at 10:49, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>> wrote:
>
> This starts the 2 week WG last call (ending on the 23rd of December)  on A General Mechanism for RTP Header Extensions to proposed standard.
>
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/
>
> This document is intended to obsolete RFC 5285 and has currently no IPR declarations on it.

I’ve reviewed this document. In general, I think it's in reasonable shape, although it could perhaps be better proof-read. However, I think Section 4.1 needs more work before this is ready for publication.

This section of the draft says:

   This specification updates the requirement from the RTP specification
   that the header extension "is designed so that the header extension
   MAY be ignored".  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.  Note that the support of
   header extension as specified in this recommendation is negotiated.
   RTP Header extensions MUST NOT be used when the presence of the
   extension has changed the form or nature of the rest of the packet in
   a way that is not compatible with the way the stream is signaled
   (e.g., as defined by the payload type).  Valid examples might include
   metadata that is additional to the usual RTP information, e.g.  Audio
   level from Client to mixer [RFC6464].  Note that some header
   extensions, for example MID [I-D.ietf-mmusic-sdp-bundle-negotiation]
   might, if removed, disrupt the behaviour of the higher-level
   application that builds on RTP, but are acceptable since they do not
   affect interoperability of the RTP stack itself.

This mis-quotes RFC 3550, and is hard to follow since it’s not clear what types of extension can be ignored, and what it means to affect interoperability if they are. I find the second sentence, in particular, to be confusing. My suggested rewording is as follows:

   The RTP specification [RFC3550] states that RTP “is designed so
   that the header extension may be ignored by other interoperating
   implementations that have not been extended”. The intent of this
   restriction is that RTP header extensions MUST NOT be used to
   extend RTP itself in a manner that is backwards incompatible with
   non-extended implementations. For example, a header extension is
   not allowed to change the meaning or interpretation of the standard
   RTP header fields, or of the RTCP Control Protocol (RTCP). Header
   extensions MAY carry metadata in addition to the usual RTP header
   information, provided the RTP layer can function if that metadata
   is missing. For example, RTP header extensions can be used to carry
   data that's also sent in RTCP, as an optimisation to lower latency,
   since they'll fall back to the original, non-optimised, behaviour if
   the header extension is not present. The use of header extensions to
   convey information that will, if missing, disrupt the behaviour of a
   higher layer application that builds on top of RTP is only acceptable
   if this doesn't affect interoperability at the RTP layer. For
   example, applications that use the SDP BUNDLE extension with the MID
   RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to
   correlate RTP streams with SDP m= lines likely won’t work with full
   functionality if the MID is missing, but the operation of the RTP
   layer of those applications will be unaffected.

Note that I removed the text “intermediaries SHOULD NOT remove such header extensions” because certain types of intermediaries, such as RTP mixers, have no choice but to remove RTP header extensions. It might make sense to say instead that some types of intermediary can’t be used if the higher layer protocol relies on header extensions to carry metadata, since those intermediaries are incompatible with header extensions.

Cheers,
Colin

--
Colin Perkins
https://csperkins.org/

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org<mailto:avt@ietf.org>
https://www.ietf.org/mailman/listinfo/avt