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

[Colin Perkins <[e-mail]>]

> On 9 Dec 2016, at 10:49, Magnus Westerlund <[e-mail]> 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/