Re: [AVT] [Fwd: I-D ACTION:draft-wenger-avt-avpf-ccm-02.txt]

[Colin Perkins <csp at csperkins.org>]

Magnus,

On 15 Feb 2006, at 10:09, Magnus Westerlund wrote:
> The updated version of the codec control messages is now available.  
> The main changes are:
>
> - Revised topology section. With discussion on how the commonly  
> used models relate to the by RTP translator and mixer concepts.
> - Updated solution for TMMBR not requiring request ACKs, instead  
> notification messages are used that suppress further requests from  
> other participants.
>
> Please provide feedback

The expanded discussion of MCUs, translators and mixers in section  
2.3 is valuable, and I'm happy to see this added. I notice two minor  
issues with it, however:

1) Figure 4 is referenced, but appears to be missing.

2) Section 2.3.4 states that "the mixer creates two different SSRC  
spaces the different domains" however my understanding of the  
behaviour of a mixer is that there is a single name space, but some  
participants appear as an SSRC in one domain, and as a CSRC (with the  
same numeric value) in the other.

Regarding section 3.5.1, would it be possible to change "Full Intra  
Request Command" into just "Full Intra Request" in the section title  
and first sentence? This gives consistency with the rest of the  
document, and makes it clearer that the source can ignore the FIR if  
sending a decoder refresh would conflict with the demands of  
congestion control.

Regarding section 3.5.2, could the temporal spatial trade-off  
acknowledgement be renamed to an announcement? This would help avoid  
turning RTCP into an explicit request-response protocol, simplifying  
the discussion in section 4.1 and making more sense for group  
communication scenarios (where currently a receiver in an MCU-based  
group can receive an acknowledgement for a request it didn't make; an  
announcement of the new trade-off is more logical), and would also  
allow the sender to make unilateral changes to the trade-off, which  
could be reflected in the receiver UI. A sender would still be  
allowed, or even encouraged, to send an announcement of the new trade- 
off when receiving a request so this won't affect functionality.

I would also recommend a careful editorial pass be made at some  
point; there are a number of rough edges to the draft.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt