[rtcweb] editorial nits: draft-ietf-rtcweb-rtp-usage-04
"Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com> Mon, 13 August 2012 14:35 UTC
Return-Path: <albrecht.schwarz@alcatel-lucent.com>
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 755BB21F8752 for <rtcweb@ietfa.amsl.com>; Mon, 13 Aug 2012 07:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.362
X-Spam-Level:
X-Spam-Status: No, score=-7.362 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Qzf6qlweYWi2 for <rtcweb@ietfa.amsl.com>; Mon, 13 Aug 2012 07:35:23 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 464AC21F8766 for <rtcweb@ietf.org>; Mon, 13 Aug 2012 07:35:23 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7DEMfAD013456 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Aug 2012 16:34:52 +0200
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 13 Aug 2012 16:33:13 +0200
From: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>
To: "csp@csperkins.org" <csp@csperkins.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Mon, 13 Aug 2012 16:33:04 +0200
Thread-Topic: editorial nits: draft-ietf-rtcweb-rtp-usage-04
Thread-Index: Ac15YIzDpGcRzNpCR2SBlY2H/Hly3A==
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC96218B57F57E@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {EB319EBA-A696-4F9D-8612-8917D1F2CB94}
x-cr-hashedpuzzle: Bvf5 LAkk L7gp MJfT NeA0 ODIc Swd1 TKmI UZge YboI Ynqg ZogW aqm3 bmV+ cyxB iEou; 3; YwBzAHAAQABjAHMAcABlAHIAawBpAG4AcwAuAG8AcgBnADsAbQBhAGcAbgB1AHMALgB3AGUAcwB0AGUAcgBsAHUAbgBkAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwByAHQAYwB3AGUAYgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EB319EBA-A696-4F9D-8612-8917D1F2CB94}; YQBsAGIAcgBlAGMAaAB0AC4AcwBjAGgAdwBhAHIAegBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAA==; Mon, 13 Aug 2012 14:33:04 GMT; ZQBkAGkAdABvAHIAaQBhAGwAIABuAGkAdABzADoAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AcgB0AGMAdwBlAGIALQByAHQAcAAtAHUAcwBhAGcAZQAtADAANAA=
acceptlanguage: de-DE, en-US
Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC96218B57F57EFRMRSSXCHMBSD_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: [rtcweb] editorial nits: draft-ietf-rtcweb-rtp-usage-04
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, 13 Aug 2012 14:35:26 -0000
Colin, Magnus, fyi, some editorial nits, regards, Albrecht Line numbers according http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtcweb-rtp-usage-04.txt Editorial change proposals: 232 RTP Media Stream: A sequence of RTP packets, and associated RTCP 233 packets, using a single synchronisation source (SSRC) that => synchronization (according RFC 3550) => ... multiple times in doc 295 participants in the session; support for randomised RTCP => randomized 407 session also effects the possibility for differentiated treatment of => affects 528 implemented using a centralised server, multi-unicast, or using IP => centralized ... multiple times 588 Request above as there there may be multiple methods to fulfill the => delete 'there' 694 optimisations of non critical functions, and is hence OPTIONAL to => optimizations 715 will support negative acknowlegdements (NACKs) for RTP data packets => acknowledgements 1247 own traffic. While is is clearly considered a bug, it is important => is is 1248 that the end-point is able to recognise and handle the case when it => recognize 1670 This in an attempt to highlight the differencies and the in many case => differences 1718 An RTP session have good support for simultanously transport multiple => simultaneously 1723 video cameras can potentially transmitt video from both to its => transmit 1730 Thus we can introduce a couple of different notiations in the below => notations 1731 two alternate figures of a single peer connection in a a point to => a a 1838 different media bit-rates to the differnt peers, thus not forcing B => different 1839 to endure the same quality reductions if there are limiations in the => limitations 1874 encoder instances each beeing associated with two different => being 1883 resource costrained will use a different implementation strategy => constrained 1918 limited to congestion control, also prefered resolution to receive => preferred 1919 based on dispaly area available is another aspect requiring => display 1920 consideration. The need for this type of descion logic does arise in => decision 1949 its operation and form new RTP packets, encrypts and integegrity => integrity 1970 in a media domain mix of the incomming RTP media streams. Then => incoming 1980 produce a Mix of all N streams for the group that are curently not => currently 2046 particpants. As each peer receives a different version produced by => participants 2070 There exist an possible implementation choice to have the RTP => "a possible" ? 2074 about the contributing sources. This removes both the functionality => functionality 2078 they can be avoide to be resolved and instead remapped between the => avoided 2080 requiresthat SSRC/CSRC are never exposed to the WebRTC javascript => space 2185 arguments and conisderations as discussed in Appendix A.3.1.1 applies => considerations 2194 mixer in another RTP session recieves media from that end-point. => receives 2257 sequence number will need to be consequitvely incremented based on => consequ... ? 2263 handled indepdentently also thus working around any SSRC collisions => independently 2265 related WebRTC MediaStream signalling must be correspondlingly => correspondingly 2272 requests comming from an end-point and decide if it can act on it => coming 2327 end-point. For example receving a 2.5 mbps video stream and then => receiving 2328 send out a 250 kbps video stream after transcoding is a vaste of => waste 2332 increasing media bit-rate futher than what is needed to represent the => further 2368 in the two different PeerConnections that are represtented by having => represented 2372 likely needed to be soruced by the translator in response to actions => sourced 2397 keymanagement. On RTP level the main functions that may be missing => key management 2398 in a legacy implementation that otherswise support RTP are RTCP in => otherwise 2433 need to change is higly dependent on what functions it need to proxy => highly 2451 packet content or media. In fact one of the more likley scenario is => likely 2455 encryption and integirty protection operation to resolve missmatch in => integrity => mismatch 2464 and the second one which is to to provide a group communication => to to 2480 forwards all the RTP/RTCP traffic and keymanagment to the end-point => key management 2551 the client A must be capable of handlilng that when determining => handling 2560 reporting in that case becomes incosistent and without explicit => inconsistent 2634 A relay approache will result in that the WebRTC end-points will have => approach 2671 to be most easily accomplished by establishing mutliple => multiple
- [rtcweb] editorial nits: draft-ietf-rtcweb-rtp-us… Schwarz, Albrecht (Albrecht)
- Re: [rtcweb] editorial nits: draft-ietf-rtcweb-rt… Colin Perkins