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

[Colin Perkins <csp at csperkins.org>]

On 24 Feb 2006, at 09:06, Magnus Westerlund wrote:
> Colin Perkins wrote:
...
> > 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.
>
> I think we are in agreement. It is the text that isn't clear  
> enough. Anything used as an SSRC in one space should only appear a  
> CSRC in the other with the exception of the Mixer itself. I think  
> the important thing which we might have missed explaining well  
> enough is the split on reporting between the spaces. The mixer  
> forwards the CSRC SDES to the other domain, but must not forward SR  
> or RRs between the domains. Suggestions on how to describe this in  
> a good way is appreciated.

I would use the words you put in that paragraph :-) The main issue is  
that things appear as an SSRC on one side, but as a CSRC on the  
other, and that SR/RR may be filtered. The main point of my comment  
was to avoid conflicting with the phrasing in RFC 3550 Section 7.1  
where it says "all RTP end systems that can communicate through one  
or more RTP translators or mixers share the same SSRC space".

...
> > 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.
>
> Well, I am fine renaming it as serves double purposes. However the  
> explicit indication of requestors are unfortunately needed. I think  
> this is an indication that this is a functionality that isn't clear  
> cut for RTCP.

I think we're in agreement here. It's clear that a response is needed  
to inform the requester that a change has been made, all I'm  
suggesting is that it be generalised accounting for the fact that  
RTCP isn't a pure request-response protocol.

Cheers,
Colin


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