Original text:
special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure. <del> As the available bandwidth has increased, and as processors an other </del>  hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware. pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be <del> possible to have all information needed to implement an WebRTC </del>  compatible implementation. 2.2. endpoints in the form of messages.  Two endpoints can have multiple data channels between them. <del> An implementation of the Interactive Connectivty Establishment </del>  (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). more than hundreds of milliseconds).  Real-time media can be used to support interactive communication. <del> The protocol implementation involved in the SDP offer/answer exchange, as defined in RFC3264 section 3. </del>  Communication that happens in order to establish, manage and control media paths and data paths. running in the browser. A commonly imagined model of deployment is the one depicted below.  On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols <del> (for example SIP RFC3261 or XMPP RFC6120) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. </del>  For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g.  SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' <del> servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over WebSockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </del>  The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is WebRTC browsers MUST implement I-D.ietf-rtcweb-jsep. WebRTC endpoints MUST implement the functions described in that <del> document that relate to the network layer (for example Bundle I- D.ietf-mmusic-sdp-bundle-negotiation, RTCP-mux RFC5761 and Trickle ICE I-D.ietf-ice-trickle), but do not need to support the API functionality described there. </del>  8.

Reviewer comments:
This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt

Revised text:
special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure.  <ins> As the available bandwidth has increased, and as processors and other </ins> hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware. pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be  <ins> possible to have all information needed to implement a WebRTC </ins> compatible implementation. 2.2. endpoints in the form of messages.  Two endpoints can have multiple data channels between them.  <ins> An implementation of the Interactive Connectivity Establishment </ins> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). more than hundreds of milliseconds).  Real-time media can be used to support interactive communication.  <ins> The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in RFC3264 section 3. </ins> Communication that happens in order to establish, manage and control media paths and data paths. running in the browser. A commonly imagined model of deployment is the one depicted below. <ins> In the figure below JS is Javascript. </ins> On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols  <ins> (e.g.  SIP RFC3261 or XMPP RFC6120) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. </ins> For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g.  SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators'  <ins> servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  XMPP over WebSockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is WebRTC browsers MUST implement I-D.ietf-rtcweb-jsep. WebRTC endpoints MUST implement the functions described in that  <ins> document that relate to the network layer (e.g.  Bundle I-D.ietf- mmusic-sdp-bundle-negotiation, RTCP-mux RFC5761 and Trickle ICE I- D.ietf-ice-trickle), but do not need to support the API functionality described there. </ins> 8.