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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Feb 2006 11:09:00 +0100

Hi,

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

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

Subject: I-D ACTION:draft-wenger-avt-avpf-ccm-02.txt
From: [email-masked]
To: [email-masked]
Date: Tue, 14 Feb 2006 18:50:02 -0500
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Codec Control Messages in the Audio-Visual Profile with Feedback (AVPF)
	Author(s)	: S. Wenger, et al.
	Filename	: draft-wenger-avt-avpf-ccm-02.txt
	Pages		: 47
	Date		: 2006-2-14
	
This document specifies a few extensions to the messages defined in
   the Audio-Visual Profile with Feedback (AVPF).  They are helpful
   primarily in conversational multimedia scenarios where centralized
   multipoint functionalities are in use. However some are also usable
   in smaller multicast environments and point-to-point calls. The
   extensions discussed are Full Intra Request, Temporary Maximum Media
   Bit-rate and Temporal Spatial Trade-off.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wenger-avt-avpf-ccm-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-wenger-avt-avpf-ccm-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-wenger-avt-avpf-ccm-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Thu, 23 Feb 2006 17:17:20 +0000

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.
> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Feb 2006 10:06:53 +0100

Colin Perkins wrote:
> 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:
> 

Okay,

we have had some problems with the auto-numbering of the figures. I 
blame the move to Word 2003. But we will look into this.

> 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.

> 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.

Yes, I think this is the right choice. We will see what we can do.

> 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 would also recommend a careful editorial pass be made at some point; 
> there are a number of rough edges to the draft.
> 

Yes, it needs more editorial work. However I and think the other authors 
agreed that with the changes made we needed reviews of the ideas more
than very well written language.

Thanks for the review.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Fri, 24 Feb 2006 15:47:34 +0000

> Colin Perkins wrote:
...
>> 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".

...
>> 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  
> 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