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

From: Alex Eleftheriadis <[email-masked]>
Date: Mon, 12 May 2014 06:51:08 +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 <[email-masked]> 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, [email-masked] 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
>> [email-masked]
>> 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:[email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Colin Perkins <[email-masked]>
Date: Tue, 13 May 2014 19:54:09 +0100

Hi Alex,

Thanks for the comments. These all look like reasonable suggestions, that we can try to incorporate into the next version.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 14 May 2014 21:16:50 +0000

Thank you. --A