Re: [AVTCORE] Topologies-update, paragraph covering relationship of RTP header extensions and RTCP

Looks Good Stephan except for one typo (RTSP --> RTCP)

As long as the middle box that is aware of the RTP Header Extension behaves
in a way consistent with the requirements of such an extension within the
context of RTP and RTCP , we should be good with the text.

Thanks
Suhas

On Tue, Nov 11, 2014 at 12:47 PM, Stephan Wenger <stewe@stewe.org> wrote:

>   Hi all,
>
> In yesterday’s AVTCORE session, we decided to include a paragraph into
> the draft that addresses Roni’s concerns as expressed in his email dated
> 9/26/2014 and discussed in the session.  Attached the proposed paragraph,
> as worked out between Roni, Jonathan Lennox, Colin Perkins, and myself.  It
> will be placed in a slightly restructured section 4.
>
> I’ll wait for comments on the list for a day or two, and then spin
> version 05 of topologies-update covering this and also fixes of the
> nits mention by Bo Burman.  I understand that this updated draft will be
> subject to another short WGLC.  Of course, comments now would make my life
> easier, so please do so if you can.
>
> Thanks,
>
> Stephan
>
>
>
>
>
>  Some RTP header extensions have relevance not only end-to-end, but also
> hop-to-hop, meaning at least some of the middleboxes in the path are
> aware of their potential presence through signaling, intercept and
> interpret such header extensions and potentially also rewrite or generate
> them.  Modern header extensions generally follow [RFC5285] which allows
> for all of the above. Examples for such header extensions include the mid
> (media ID) in [draft-ietf-mmusic-sdp-bundle-negotiation-12].  There is also
> a generalization of mapping RTCP SDES into an RTP header extension
> [draft-westerlund-avtext-sdes-hdr-ext-02].
>
>
>
> When such header extensions are in use, any middle box that understands
> it must ensure consistency between the extensions it sees and/or generates,
> and the RTCP it receives and generates.  For example, the mid of bundle is
> sent in an RTP header extension and also in an RTCP SDES message.  This
> apparent redundancy was introduced as unaware middleboxes may choose to
> discard RTP header extensions.  Obviously, inconsistency between the media
> ID sent in the RTP header extension and in the RTSP SDES message could lead
> to undesirable results, and, therefore, consistency is needed.  Middleboxes
> unaware of the nature of a header extension, as specified in [RFC5285], are
> free to forward or discard header extensions.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>