Subject: Re: [AVTCORE] Topologies and RTP header extensions

From: Stephan Wenger <[email-masked]>
Date: Tue, 7 Oct 2014 17:35:15 +0000

Hi Roni,

Sorry for my late reply.

As a matter of principle, a document like the topologies will *always* be incomplete.  It's the nature of overview documents such as this one.

To be a bit more specific, if we were adding caveat paragraphs of what people need to keep in mind for all conceivable (or currently discussed) environments and circumstances, we get an unreadable document.  We are well on the way towards that already (see for example the RAMS related stuff, which goes IMO somewhat overboard).  I rather have a document that is admittedly short on addressing certain niche scenarios, then one that tries to cover every possible angle.

As for the substance, please see inline.

Thanks,
Stephan

From: Roni Even <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 26, 2014 at 8:06 AM
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Jonathan Lennox <[email-masked]<mailto:[email-masked]>>, Magnus Westerlund <[email-masked]<mailto:[email-masked]>>
Subject: Topologies and RTP header extensions

Hi Stephan,
I am looking at the issue of mapping RTP streams to SDP and CLUE. For SDP there is a current proposal in the Bundle draft that is using RTP header extensions and RTCP.
I am looking at the topologies draft to see if these solutions works and noticed that the draft is not complete about RTP header extensions.

Agreed that the doc at present does not cover RTP header extensions in the context of consistency with RTCP signaling.  I'm not sure that it must cover that, though...

I think that as a starting point it should say as a general statement that middle boxes (mixers, translators,...) must see that the RTP header extensions are correct and verify that duplicate information in RTP header extensions and RTCP will remain consistent.

So two aspects here:

(1) "middle boxes (mixers, translators,...) must see that the RTP header extensions are correct".  I think that this statement implies that the middle box must be aware of the RTP header extension syntax, and parse it, and perhaps interpret in the context of it's knowledge of the signaling and RTCP before sending it on.
I don't think that is universally the case.  To the contrary, I think that the more common policy for middleboxes today is to consider RTP header extensions as supplementary junk, and never look into them (but typically also not strip them, as they may be useful for someone else in the system).  Frankly, in my limited and outdated experience, the majority of RTP header extensions on the wire do not follow any RFC, but are rather proprietary info of a vendor.  A middle box, by definition, cannot deal with that information if it's not produced by that vendor.
It may well be that in an environment like CLUE, a very different strategy is warranted and necessary.  But I'm not sure a broadly applicable document like the topologies doc should address that particular scenario.  And it should certainly not make a broad statement that at least in some cases is plainly incorrect.  Perhaps it's better to stay silent?

(2) "verify that duplicate information in RTP header extensions and RTCP will remain consistent".  Really?  I guess what you are referring to is to ensure that if the middle box rewrites RTCP (in a translator, or creates new RTCP in a mixer), then that RTCP needs to take the content of the RTCP as well as the header extensions into account.  Surely it needs to do that in a certain subset of systems.  But it very much depends on the nature of the header extensions.  I have already made my case for proprietary header extensions.  As for standards, for example if the header extension were audio volume related, would the middle box care?  Not really.  (Only in the context of audio mixing itself of course, but not in the context of RTCP).

Roni

---

From: "Roni Even" <[email-masked]>
Date: Wed, 8 Oct 2014 00:36:33 +0300

Hi Stephan,

The issue of consistency may be important. For example in "bundle", used
also by RTCweb and not only CLUE,  section 13 defines an SDES message and
RTP header extension that carries the mid value from the SDP to map the RTP
stream to the SDP m-line. In this case if the middle box is a conference
bridge it will send new SDP to the participants with new mid values, it
should send the correct SDES with the new mid value and the correct SSRC but
should verify that the RTP header extension will also be correct, this is
important for media switching cases.

You are making a good point about "standard header extensions" still RFC5285
created an IANA registry for RTP header extensions so maybe not have a
general statement but about RTP header extensions supported by the middle
box, based on its support of the SDES message. Note that RTP header
extensions may be stripped by the middle box and this is why RTCP SDES are
also sent.

Roni

From: Stephan Wenger [mailto:[email-masked]] 
Sent: 07 October, 2014 8:35 PM
To: Roni Even; [email-masked]
Cc: 'Jonathan Lennox'; Magnus Westerlund
Subject: Re: Topologies and RTP header extensions

Hi Roni, 

Sorry for my late reply.

As a matter of principle, a document like the topologies will *always* be
incomplete.  It's the nature of overview documents such as this one. 

To be a bit more specific, if we were adding caveat paragraphs of what
people need to keep in mind for all conceivable (or currently discussed)
environments and circumstances, we get an unreadable document.  We are well
on the way towards that already (see for example the RAMS related stuff,
which goes IMO somewhat overboard).  I rather have a document that is
admittedly short on addressing certain niche scenarios, then one that tries
to cover every possible angle.

Thanks,

Stephan 

From: Roni Even <[email-masked]>
Date: Friday, September 26, 2014 at 8:06 AM
To: Stephan Wenger <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Jonathan Lennox <[email-masked]>, Magnus Westerlund
<[email-masked]>
Subject: Topologies and RTP header extensions

Hi Stephan,

I am looking at the issue of mapping RTP streams to SDP and CLUE. For SDP
there is a current proposal in the Bundle draft that is using RTP header
extensions and RTCP.

I am looking at the topologies draft to see if these solutions works and
noticed that the draft is not complete about RTP header extensions.

Agreed that the doc at present does not cover RTP header extensions in the
context of consistency with RTCP signaling.  I'm not sure that it must cover
that, though.

I think that as a starting point it should say as a general statement that
middle boxes (mixers, translators,.) must see that the RTP header extensions
are correct and verify that duplicate information in RTP header extensions
and RTCP will remain consistent.

So two aspects here:

(1) "middle boxes (mixers, translators,.) must see that the RTP header
extensions are correct".  I think that this statement implies that the
middle box must be aware of the RTP header extension syntax, and parse it,
and perhaps interpret in the context of it's knowledge of the signaling and
RTCP before sending it on.

I don't think that is universally the case.  To the contrary, I think that
the more common policy for middleboxes today is to consider RTP header
extensions as supplementary junk, and never look into them (but typically
also not strip them, as they may be useful for someone else in the system).
Frankly, in my limited and outdated experience, the majority of RTP header
extensions on the wire do not follow any RFC, but are rather proprietary
info of a vendor.  A middle box, by definition, cannot deal with that
information if it's not produced by that vendor.

It may well be that in an environment like CLUE, a very different strategy
is warranted and necessary.  But I'm not sure a broadly applicable document
like the topologies doc should address that particular scenario.  And it
should certainly not make a broad statement that at least in some cases is
plainly incorrect.  Perhaps it's better to stay silent?

(2) "verify that duplicate information in RTP header extensions and RTCP
will remain consistent".  Really?  I guess what you are referring to is to
ensure that if the middle box rewrites RTCP (in a translator, or creates new
RTCP in a mixer), then that RTCP needs to take the content of the RTCP as
well as the header extensions into account.  Surely it needs to do that in a
certain subset of systems.  But it very much depends on the nature of the
header extensions.  I have already made my case for proprietary header
extensions.  As for standards, for example if the header extension were
audio volume related, would the middle box care?  Not really.  (Only in the
context of audio mixing itself of course, but not in the context of RTCP).

 

Roni