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

[Colin Perkins <[e-mail]>]

Albrecht,

Thanks for the detailed feedback. The -05 version of the draft should fix most of these, although some are differences between English and American that I have no intention of fixing ;-)

Cheers,
Colin



On 13 Aug 2012, at 15:33, Schwarz, Albrecht (Albrecht) wrote:
> 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
>       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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



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