Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-13.txt

Alex Eleftheriadis <alex@vidyo.com> Mon, 12 May 2014 06:51 UTC

Return-Path: <alex@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7D1A0420 for <rtcweb@ietfa.amsl.com>; Sun, 11 May 2014 23:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBSbg11X32IB for <rtcweb@ietfa.amsl.com>; Sun, 11 May 2014 23:51:17 -0700 (PDT)
Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 94CEC1A041B for <rtcweb@ietf.org>; Sun, 11 May 2014 23:51:16 -0700 (PDT)
X-Note-AR-ScanTimeLocal: 5/12/2014 2:51:10 AM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: alex@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-58/SG:2 5/12/2014 2:50:51 AM
X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.862325 p=-0.986534 Source White
X-Signature-Violations: 0-0-0-13019-c
X-Note-419: 15.6004 ms. Fail:0 Chk:1340 of 1340 total
X-Note: SCH-CT/SI:0-1340/SG:1 5/12/2014 2:51:07 AM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->
X-Note-Sending-IP: 162.209.16.213
X-Note-Reverse-DNS: mail1.vidyo.com
X-Note-Return-Path: alex@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 96234181; Mon, 12 May 2014 02:51:09 -0400
Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Mon, 12 May 2014 01:51:09 -0500
From: Alex Eleftheriadis <alex@vidyo.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-13.txt
Thread-Index: AQHPXvfmeuYcI7i6ykmMzZ63gXbx1JsfhuwAgB1sDIA=
Date: Mon, 12 May 2014 06:51:08 +0000
Message-ID: <5DB48F3D-980D-43CF-83BF-4E12BFC8B794@vidyo.com>
References: <20140423132741.9210.61684.idtracker@ietfa.amsl.com> <5357C102.2060606@ericsson.com>
In-Reply-To: <5357C102.2060606@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [85.72.60.87]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <C3B6E61F5F9DB14BBC0051613C0C4262@vidyo.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NAL2j_3hEAdxexUVHts6coKAYfE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-13.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 12 May 2014 06:51:19 -0000

Hi Magnus/all. 

Great document. I took the time to write down some comments, most editorial but not all. I list them below sorted by page number. 

Regards,

--Alex

* * * * * * * * * * * * * *

-- p. 17, Section 6

The first paragraph seems to suggest that the overhead is always non-trivial. In fact, techniques such as the one mentioned in Section 6.1 can be done with very small overhead (bits) and, specifically, without requiring "a lower base encoding quality". The paragraph can be read to suggest that such lowering is *always* required for robustness. 

-- p. 23, 3rd paragraph

"both effective congestion control" -> delete "both".

-- p. 26, 2nd paragraph

"Thus it is possible for multiple source packet streams to share encoded streams (but not packet streams), but this is an implementation choice to try to utilise such optimisations."

I am not sure I understand this. An example would help. (The sentence needs a rewrite anyway.)

-- p. 26, 3rd paragraph

"and don't forces a end-point to change" -> "and does not force an end-point to change"

-- p. 27, 1st paragraph

"can request that the ... to be the same" -> delete "to". 

"this allow for synchronization" -> "this allows for synchronization"

-- p. 27, 3rd paragraph

"that receives an MediaStreamTrack" -> "that receives a MediaStreamTrack"

"for its the sent streams" -> "for its sent streams".

"etc followed" -> "etc., followed"

-- p. 30, 2nd paragraph

"possible to accomplished by establishing" -> "possible to be accomplished by establishing"

-- p. 31, 1st paragraph

"It it believed" -> "It is believed"

Also, the statement in that last sentence: "It is believed that these advantages outweigh the limitations in debugging power."  is putting it mildly :-)

-- p. 34, 4th paragraph

"the second the actual mechanism to prioritize packets" -> "the second consisting of the actual mechanism to prioritize packets".

-- p. 36, 12.2.1 title

"Media Source" -> "Media Source Identification"

--p. 36, 2nd and 3rd paragraphs

IN the 2nd paragraph it is stated "to avoid exposing the SSRC/CSRC name space to JavaScript applications". In the 3rd: "This information [audio level for each contributing source] can usefully be exposed in the user interface."

To make this point, you need to explain how the audio level information is going to be carried across the API or point somewhere. 

-- p. 37, 1st, 2nd, and 4th paragraphs

"both end-points uses an new SSRC" -> "both end-points use a new SSRC"

"reject a end-points usage of an SSRC" -> "reject an end-point's usage of an SSRC"

"While is is clearly considered" -> "While it is clearly considered"

-- general

Section 11 appears to require at least one more editorial pass.

Make sure you use British or US English consistently (i.e., optimise vs. optimize :-)





On Apr 23, 2014, at 4:32 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

> WG,
> 
> We authors have been doing some editing on this version to take care of
> the last known issues. This includes the text that has been discussed on
> the list lately. It also contains an expanded example about RTCP
> bandwidth (see Section 7.2). Further we have reviewed the terminology
> usage in the document, and applied the AVTEXT grouping taxonomy.
> 
> So, we authors now believe this to be ready for WG last call.
> 
> Cheers
> 
> Magnus
> 
> On 2014-04-23 15:27, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.
>> 
>>        Title           : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
>>        Authors         : Colin Perkins
>>                          Magnus Westerlund
>>                          Joerg Ott
>> 	Filename        : draft-ietf-rtcweb-rtp-usage-13.txt
>> 	Pages           : 45
>> 	Date            : 2014-04-23
>> 
>> Abstract:
>>   The Web Real-Time Communication (WebRTC) framework provides support
>>   for direct interactive rich communication using audio, video, text,
>>   collaboration, games, etc. between two peers' web-browsers. This
>>   memo describes the media transport aspects of the WebRTC framework.
>>   It specifies how the Real-time Transport Protocol (RTP) is used in
>>   the WebRTC context, and gives requirements for which RTP features,
>>   profiles, and extensions need to be supported.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-13
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-13
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb