Change:
For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a <del> standardized signaling mechanism (e.g.  SIP over Websockets) or a </del> <ins> standardized signaling mechanism (e.g.  SIP over WebSockets) or a </ins> proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. <del> XMPP over Websockets or BOSH) or a proprietary signaling mechanism </del> <ins> XMPP over WebSockets or BOSH) or a proprietary signaling mechanism </ins> used between the application running in the browser and the web server. <del> The choice of protocols, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. </del> <ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. </ins> The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as:

Discussion:
From Magnus, on mailing list, with response: Actually both the IETF effort and the W3C effort consists of lots of moving parts. Would "A Javascript API, defined by a set of specifications [cite]" scan better?
"This means that two vital interfaces need specification: The protocols that browsers talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality." I would add a "use to" between "browsers" and "talk"
You write "Websockets" in many places. The w3c spec seems to prefer "WebSockets"
"The choice of protocols, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document." I would like to add "inter-server signaling" before "protocols" to be very clear here.
"Data framing: RTP and other data formats that serve as containers, and their functions for data confidentiality and integrity." Should SCTP be mentioned here for clarity?
All suggestions taken except the "inter-server signalling" one - the choice of protocols for client-server signalling is also out of scope for this document, so I added "client-server and inter-server" instead.
"ICE Agent: An implementation of the Interactive Connectivty Establishment (ICE) [RFC5245] 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)." Just a not to verify that this is right: RFC 5245 defines "Agent" the same way as this document specifies "SDP agent" and refers to RFC 3264 for a definition of Agent. The term "Ice Agent" appear later in the terminology section though not as a separate definition but as an explanation of controlling and controlled agent... Nit picking here. ;-)
"Signaling: Communication that happens in order to establish, manage and control media paths." Signaling is also used for data channels
Data channels lack a term here. You have defined media and media path
Re Agent: RFC 5245 section 2 says "In a typical ICE deployment, we have two endpoints (known as AGENTS in RFC 3264 terminology) that want to communicate.

They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can perform an offer/answer exchange of SDP [RFC3264] messages." RFC 5245bis says "In a typical ICE deployment, we have two endpoints (known as ICE AGENTS) that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can exchange ICE candidates." The binding to SDP has apparently been loosened in 5245bis. I think we should move the reference to 5245bis - we already have normative dependencies on that from dualstack-fairness and bundle, so it's not a new blocker.
Added data channel and moved pointers to 5245bis.
" The total WebRTC effort consists of two pieces:" I would say "two major pieces" or "parts" since we have a lot of documents and components, so just saying two pieces seems an underestimation.
" Together, these two specifications aim to provide an environment where Javascript embedded in any page, viewed in any compatible browser, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, where the browser environment does not constrain the types of application in which this functionality can be used." This is a very complex sentence. Can this be simplified?
I tried restructuring it.
"It defines terms used by other pieces of specification," Doesn't feel right to me, but I could be reading in Swenglish here. "other specifications" or "other pieces of specifications"
"other pieces of specification" should probably read "other parts of the WebRTC protocol suite". The intent was to capture that terms of art like "WebRTC browser" and "WebRTC endpoint" are defined here and used elsewhere.
Changed to "other parts of the WebRTC protocol specifications".
"This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web"." Later in the document you mention non-browsers such as gateways. Do you want to include them in the abstract? ..."to make sure all the parts"... I feel that "that" is missing between "sure" and "all"
Not really - the focus here is that it has to be usable on the Web.

There's time enough to mention non-browsers later in the document. My English sense says that the sentence works both with and without "that" - I'll defer to native speakers of US-English for this one.
Closing as "no change needed" (editor's judgment).