Change:
risk is created by allowing calls at all from a page fetched over HTTP. <del> Even if calls are only possible from HTTPS [RFC2818] sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page finer-grained.  Thus, it is also dangerous to allow WebRTC functionality from HTTPS origins that embed mixed-content.  Note: this issue is not restricted to PAGES which contain mixed content.  If a page from a given origin ever loads mixed content then it is possible for a network attacker to infect the browser's notion of that origin semi-permanently. </del> <ins> Even if calls are only possible from HTTPS [RFC2818] sites, if those sites include active content (e.g., JavaScript) from an untrusted site, that JavaScript is executed in the security context of the page finer-grained.  This could lead to compromise of a call even if the parent page is safe.  Note: this issue is not restricted to PAGES which contain untrusted content.  If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that attacker to infect the browser's notion of that origin semi- permanently. </ins> 4.2.

Discussion:
This seems like it should fix things
It's been there since the beginning, but the point is that people often think that if the page itself doesn't have malicious content then it's fine, but that's not true. Anyway, I'm comfortable with that piece unless someone objects to the content.
In Adam's AD review: I can't parse this sentence. Consider reworking. Even if calls are only possible from HTTPS [RFC2818] sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page [finer-grained].
NAME do you have a proposal here?
NAME how about the following knowing that you're trying to bridge the previous that talks about HTTP origins: It is also dangerous to allow WebRTC functionality from HTTPS [RFC2818] origins that embed mixed content because if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site that JavaScript is executed in the security context of the page [finer-grained]. Note this would replace the 1st two sentences in the last para of §4.1.4 copied here for convenience: Even if calls are only possible from HTTPS [RFC2818] sites, if the site embeds active content (e.g., JavaScript) that is fetched over HTTP or from an untrusted site, because that JavaScript is executed in the security context of the page [finer-grained]. Thus, it is also dangerous to allow WebRTC functionality from HTTPS origins that embed mixed content.
Has this been overtaken by events? I mean, while it might have been the case that some browsers permitted the use of active mixed content when this was originally written, I don't believe that any currently do. Could the text be removed?
I guess it could, but this is the section on "Security Properties of the Calling Page" so maybe for posterity we make this tweak, but also add to the end of the paragraph: Note: the issue of active mixed content was an issue, but is now implemented by browsers. And, (not having read the link entirely) we also informatively point to this W3C draft?