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

From: Stephan Wenger <[email-masked]>
Date: Tue, 11 Nov 2014 22:47:50 +0000

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.

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 11 Nov 2014 13:28:39 -1000

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 12 Nov 2014 20:02:04 +0000

Thank you.
Fixed.
Stephan

From: Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 11, 2014 at 13:28
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jonathan Lennox <[email-masked]<mailto:[email-masked]>>, Colin Perkins <[email-masked]<mailto:[email-masked]>>
Subject: Re: [AVTCORE] Topologies-update, paragraph covering relationship of RTP header extensions and 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 <[email-masked]<mailto:[email-masked]>> 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

_______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avt