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

[Stephan Wenger <[e-mail]>]

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.