[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 []) 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 ([]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([]) 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-cr-puzzleid: {EB319EBA-A696-4F9D-8612-8917D1F2CB94}
acceptlanguage: de-DE, en-US
Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC96218B57F57EFRMRSSXCHMBSD_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
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,

Line numbers according

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