[rtcweb] Review of draft-perkins-rtcweb-usage-03 (Re: Fwd: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt)

Harald Alvestrand <harald@alvestrand.no> Mon, 29 August 2011 13:31 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBB221F8A91 for <rtcweb@ietfa.amsl.com>; Mon, 29 Aug 2011 06:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.144
X-Spam-Level:
X-Spam-Status: No, score=-106.144 tagged_above=-999 required=5 tests=[AWL=4.455, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l23-TRG+2AO0 for <rtcweb@ietfa.amsl.com>; Mon, 29 Aug 2011 06:31:46 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 40EE821F8742 for <rtcweb@ietf.org>; Mon, 29 Aug 2011 06:31:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8C4639E0C4 for <rtcweb@ietf.org>; Mon, 29 Aug 2011 15:31:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl3EACNhuxD5 for <rtcweb@ietf.org>; Mon, 29 Aug 2011 15:31:53 +0200 (CEST)
Received: from [172.16.40.245] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8637239E087 for <rtcweb@ietf.org>; Mon, 29 Aug 2011 15:31:53 +0200 (CEST)
Message-ID: <4E5B9513.6040606@alvestrand.no>
Date: Mon, 29 Aug 2011 15:33:07 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <20110828175441.24054.11368.idtracker@ietfa.amsl.com> <57BFE815-5A39-4AC5-9787-80E13D34B68E@csperkins.org>
In-Reply-To: <57BFE815-5A39-4AC5-9787-80E13D34B68E@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] Review of draft-perkins-rtcweb-usage-03 (Re: Fwd: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2011 13:31:47 -0000

Colin, I really like this version!

There might want to be a placeholder about multiplexing, saying "we will 
return to this issue after more discussion". Otherwise, it seems to me 
we're setting up the expectation that this will be handled entirely in 
some other document - I think the end product of the WG needs to discuss 
it, and it seems logical that some aspect of it should go here.

Some detailed comments:

- In Figure 2, section 1.1, I think you're making the assumption that 
multi-unicast topologies will use a single shared RTP session (SSRC 
number space) for all the links. This is not obvious; it's possible to 
build this topology on point-to-point RTP sessions too.

- In section 3, you make the point that improper signalling of bandwidth 
can cause failure to interoperate (because of differing RTCP timings). 
Is there a (possibly theoretical) problem with interoperation between 
RTP/AVP and RTP/AVPF too, or have we verified that the AVPF profile 
always sends enough RTCP packets that AVP-conformant endpoints don't 
time out?

- In section 6, I would recommend removing the point about scenarios 
with mixers using point-to-point RTP sessions are "not well utilizing 
the mechanisms of RTP" - I think people's engineering tradeoffs should 
be respected.
I'm fine with leaving in the comment about protocol violations (although 
I'd like to be more specific about what they are - protocols shouldn't 
be violated; if people "have" to do that, there's something wrong with 
the protocol).

- In the list of other extensions, section 6.2, you say that two 
extensions are "not recommended" - is this a recommendation against 
(like NOT RECOMMENDED would be), or simply a declaration that their use 
or non-use is of no concern?

- there are some sections with garbled grammar (the last paragraph of 
section 7.2, before 7.2.1, is particularly irksome to the eye), but I 
assume that this will be reviewed in later versions; the meaning comes 
through.



On 08/28/11 19:59, Colin Perkins wrote:
> Begin forwarded message:
>> From: internet-drafts@ietf.org
>> Date: 28 August 2011 18:54:41 GMT+01:00
>> Subject: New Version Notification for draft-perkins-rtcweb-rtp-usage-03.txt
>>
>> A new version of I-D, draft-perkins-rtcweb-rtp-usage-03.txt has been successfully submitted by Colin Perkins and posted to the IETF repository.
>>
>> Filename:	 draft-perkins-rtcweb-rtp-usage
>> Revision:	 03
>> Title:		 RTP Requirements for RTC-Web
>> Creation date:	 2011-08-28
>> WG ID:		 Individual Submission
>> Number of pages: 22
> This version makes the following changes relative to the -02 draft:
>
> - Removed discussion of multiplexing for RTP sessions entirely, pending submission of a proposal for multiplexing audio and video within an RTP session (as discussed at IETF 81).
>
> - Added a reference to draft-ietf-avtcore-srtp-vbr-audio-03 in Security Considerations.
>
> - Added a recommendation that draft-ietf-avtcore-srtp-encrypted-header-ext-00 be used when the client-to-mixer and mixer-to-client audio level indication RTP header extensions are in use in SRTP encrypted sessions.
>
> - Added Slice Loss Indication and Reference Picture Selection Indication messages as OPTIONAL loss tolerance mechanisms.
>
> Comments and feedback are welcome.
>