Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2032-bis-12.txt

From: [email-masked]
Date: Wed, 18 Jan 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for H.261 Video Streams
	Author(s)	: R. Even
	Filename	: draft-ietf-avt-rfc2032-bis-12.txt
	Pages		: 24
	Date		: 2006-1-18
	
This memo describes a scheme to packetize an H.261 video stream for
   transport using the Real-time Transport Protocol, RTP, with any of
   the underlying protocols that carry RTP.

   The memo also describes the syntax and semantics of the SDP
   parameters needed to support the H.261 video codec.  A media type
   registration is included for this payload format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-12.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-ietf-avt-rfc2032-bis-12.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-ietf-avt-rfc2032-bis-12.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.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jan 2006 10:21:20 +0100

Hi Roni,

I have looked at the updated draft. I do have some comments:

Section 5:

The first method is by using the
    Extended RTP Profile for RTCP-based Feedback and sending RTCP generic
    control packets as described in draft-ietf-avt-rtcp-feedback [RFC-
    XXX].  The second method is by using the application protocol
    specific commands like H.245 [ITU.H245] FastUpdateRequest.

Not what I tried to comment on. The form I would liked to see would be:
    The first method is by using the
    Extended RTP Profile for RTCP-based Feedback and sending RTCP generic
    control packets as described in RFC YYYY [rtcp-feedback].  The 
second method is by using the application protocol
    specific commands like H.245 [ITU.H245] FastUpdateRequest.

So please change back the reference itself. It is important that the 
RFC-editor and anyone else reading the draft can know what the reference is.

Section 6.2.1:

The terminal may announce send capabilities.

I don't think this is sufficient because no explanation is provided how 
this would be done. Do you mean that a senders capabilities can be 
expressed in offers or answers for sendonly streams? In any case further 
clarification on how and when one can express those capabilities should 
be included. By the way is it assumed that one sender capabilities 
equals one receiver capabilities?

Section 6.2.1:
   "New implementations SHALL specify at least one supported picture
    size."

Here I see some problem using "New implementations" I think it would be 
much clearer what is meant if one writes:

"Implementations following this specification SHALL ..."

In the same way the following sentence:

If the receiver does not specify the picture size /MPI parameter then	it 
is safe to assume that it is an older implementation. The sender		is 
safe to send QCIF resolution with MPI=1.

Could be further clarified into:

If the receiver does not specify the picture size /MPI parameter then	 
it is safe to assume that it is an implementation that follows RFC 2032.

However the next sentence I think is also a bit problematic. It is not 
guaranteed that a receiver supports QCIF with MPI=1. However we do 
recommend implementations to do that assumption. Therefore I would rewrite:

The sender is safe to send QCIF resolution with MPI=1.

Into:

In that case it is RECOMMENDED to assume that such a receiver supports 
reception of QCIF resolution with MPI=1.

Section 8:

You haven't updated the second paragraph to express if H.261 shows any 
significant non uniformity in the decoding operations due to input that 
makes it vulnerable to Denial of Service attacks this way. I think a new 
sentence after the first one that express some attempt to qualify that 
risk in H.261. To my understanding H.261 will show some non-uniformity 
but not a major one.

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]