[rtcweb] editorial nits: draft-ietf-rtcweb-rtp-usage-04

["Schwarz, Albrecht (Albrecht)" <[e-mail]>]

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