Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a note controlling exposure of remote candidate addresses #381

Merged
merged 5 commits into from
Dec 12, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 14 additions & 1 deletion webrtc-stats.html
Original file line number Diff line number Diff line change
Expand Up @@ -2936,7 +2936,7 @@ <h3>
<pre class="idl">dictionary RTCIceCandidateStats : RTCStats {
DOMString transportId;
RTCNetworkType networkType;
DOMString address;
DOMString? address;
long port;
DOMString protocol;
RTCIceCandidateType candidateType;
Expand Down Expand Up @@ -2989,6 +2989,19 @@ <h2>
addresses, and fully qualified domain names (FQDNs). See
[[!RFC5245]] section 15.1 for details.
</p>
<p>
The user agent should make sure that only remote candidate addresses that the web
application has configured on the corresponding RTCPeerConnection are exposed;
This is especially important for peer reflexive remote candidates.

By default, the user agent MUST leave the 'address' member as null in the
RTCICECandidateStats dictionary of any remote candidate. Once a RTCPeerConnection
instance learns on an address by the web application using <a
href="https://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-addicecandidate">addIceCandidate</a>,
the user agent can expose the 'address' member value in any remote
RTCIceCandidateStats dictionary of the corresponding RTCPeerConnection that
matches the newly learnt address.
</p>
</dd>
<dt>
<dfn><code>port</code></dfn> of type <span class="idlMemberType"><a>long</a></span>
Expand Down