Thanks Robert, I get your point and I think it is valid.
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: den 7 juli 2015 20:34
To: Bo Burman; ietf(_at_)ietf(_dot_)org;
draft-ietf-avtext-rtp-grouping-taxonomy(_at_)ietf(_dot_)org;
avtext(_at_)ietf(_dot_)org
Subject: Re: Genart Telechat review: draft-ietf-avtext-rtp-grouping-taxonomy-07
On 7/7/15 12:22 PM, Bo Burman wrote:
Regarding your remaining nit:
Am I interpreting you correctly that you are concerned with RTP streams that
only sends RTCP, never anything else?
Yes.
We have two concepts in the draft that are affected by this; Source RTP Streams
and Redundancy RTP Streams. If no RTP data is ever sent, how do we distinguish
between an “empty” Source RTP Stream and an “empty” Redundancy RTP Stream?
I'm not sure why you would need to. Maybe that's why I don't understand why you
need the qualification in the first place?
[BoB] In practice, you clearly don’t, but this is about naming. It should be
possible to avoid confusion with some careful wording (see below).
Would it be enough with a formulation saying that _if_ any RTP data is ever
sent, a Source RTP Stream would take that from an Encoded Stream? Would that
take care of your concern?
Probably.
Think of it this way - look at Figure 1 in the current draft.
Consider an encoder that does silence suppression as a special case of VBR
encoding, and the case I mention where silence suppression is constantly on,
and the resulting bit rate is zero. Now, after encoding, and packetizing, you
hit the new RTP-based Security boxes, which are configured through some magic
to combat the known security issues with using VBR encodings by producing a
constant rate output. You still want to talk about source streams in this case
even if they're empty - while there aren't packets going into that security
box, there are lots of packets coming out.
[BoB] OK. I agree that a slight re-formulation is needed where the requirement
to send data in the Encoded Stream is removed. Please notify me when it is
appropriate to issue another revision of the document.
RjS
From: Robert Sparks [mailto:rjsparks(_at_)nostrum(_dot_)com]
Sent: den 6 juli 2015 22:41
To: General Area Review Team;
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org>;
draft-ietf-avtext-rtp-grouping-taxonomy(_at_)ietf(_dot_)org<mailto:draft-ietf-avtext-rtp-grouping-taxonomy(_at_)ietf(_dot_)org>;
avtext(_at_)ietf(_dot_)org<mailto:avtext(_at_)ietf(_dot_)org>
Subject: Genart Telechat review: draft-ietf-avtext-rtp-grouping-taxonomy-07
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-avtext-rtp-grouping-taxonomy-07
Reviewer: Robert Sparks
Review Date: 6 Jul 2015
IETF LC End Date: past
IESG Telechat date: 9 Jul 2015
Summary: Ready for publication as an Informational RFC
Thanks for addressing the comments I made at LC.
Very small nit:
I still worry that with "at least some content ... at some point during its
lifetime" that you are improperly excluding streams that may never send RTP
packets (because of silence suppression or the way a codec works), when RTCP
will be sent. This could happen in a multimedia situation where multiple
microphones are signaled, but one just happens to never get used for example.