Fix invalid WebRTC usernameFragment example

[Josh-Cena]

Fix #28171. I have no idea if this code is supposed to work, but at least it's sound type-wise.

[github-actions]

Preview URLs

• /en-US/docs/Web/API/RTCIceCandidate/usernameFragment

[hamishwillee]

The getParameters is present on the returned receiver, not on the transport. I think the correct fix is this:

Suggested change

	const parameters = receiver.transport.iceTransport.getRemoteParameters();
	const parameters = receiver.getParameters();

Note, I don't really understand all this deeply either, but my understanding is that the candidate is the proposal from the remote end. We're looking for candidates that match the one we're already using so that we have the same session - others are not relevant to this connection. Upshot, this candidate is something we store on the receiver, not something back from the other end. I could be horribly wrong though. Really just highlighting this for @sideshowbarker who probably actually understands all this.

[Josh-Cena]

That's what one would think, but this returns an RTCRtlsParameters which doesn't have the usernameFragment member. The code here gets an RTCICEParameters which seems to be the only other parameter dictionary that has a usernameFragment member.

[hamishwillee]

Good point. It looks like you might also get it from receiver.transport.iceTransport.getLocalParameters() but my understanding is that the values should be the same on both ends as it is "for the session". So this makes sense.

I'm going to approve because, as you say, this looks like the only place it can come from.