Original text:
risk is created by allowing calls at all from a page fetched over HTTP. <del> Even if calls are only possible from HTTPS 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 </del>  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 There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it.  Because <del> ICE keepalives are indications, they will not work here.  I-D.ietf- rtcweb-stun-consent-freshness describes the mechanism for providing consent freshness. </del>  4.2.2. for more details.)  This service must be provided for both data and voice/video.  Ideally the same security mechanisms would be used for both types of content.  Technology for providing this service (for <del> instance, SRTP RFC3711, DTLS RFC4347 and DTLS-SRTP RFC5763) is well </del>  understood.  However, we must examine this technology to the WebRTC context, where the threat model is somewhat different. provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to RFC6222 rather than the privacy preserving <del> mode of I-D.ietf-avtcore-6222bis).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </del>  4.4.2.

Reviewer comments:
I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.

Revised text:
risk is created by allowing calls at all from a page fetched over HTTP.  <ins> 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 </ins> 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 There also needs to be some mechanism for the browser to verify that the target of the traffic continues to wish to receive it.  Because  <ins> ICE keepalives are indications, they will not work here.  RFC7675 describes the mechanism for providing consent freshness. </ins> 4.2.2. for more details.)  This service must be provided for both data and voice/video.  Ideally the same security mechanisms would be used for both types of content.  Technology for providing this service (for  <ins> instance, SRTP RFC3711, DTLS RFC6347 and DTLS-SRTP RFC5763) is well </ins> understood.  However, we must examine this technology to the WebRTC context, where the threat model is somewhat different. provides a number of possible persistent identifiers such as DTLS certificates (if they are reused between connections) and RTCP CNAMES (if generated according to RFC6222 rather than the privacy preserving  <ins> mode of RFC7022).  In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies).  Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers.  In addition, IP addresses can be a source of call linkage I-D.ietf-rtcweb-ip-handling </ins> 4.4.2.