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

Hi Roni,

Apologies for the slow reply – the text you added in -06 to address this looks good to me.

Colin

> On 2 Jan 2017, at 13:12, Roni Even <roni.even@huawei.com> wrote:
> 
> 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 <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/ <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/ <https://csperkins.org/>
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org <mailto:avt@ietf.org>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

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