-
Notifications
You must be signed in to change notification settings - Fork 42
RTCIceGathererIceErrorEvent hostCandidate #474
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
Comments
Also last WebRTC has differences in definition... WebRTC:
ORTC:
I think ti's WebRTC that has the mistake with |
Yes, WebRTC has the error with statusText. If RTCIceGatherPolicy === "nohost" then no host candidates would be gathered but the host candidate would still exist and be filled in within the dictionary. |
All we want here is the IP address and port of the host candidate, not everything that is in the RTCIceGatherCandidate object: dictionary RTCIceCandidate { |
@aboba Assuming we need the host information at all (which is a different justification), then I would say a pointer to the candidate object (not duplicate of the information contained within) is needed to more easily correlate fully, not just the DOMString; unless the assumption is that this will only happen with UDP-based host candidates, never TCP, and thus there's enough to disambiguate with just the host ip+port string (probably true I'm guessing). But then again, I'm not sure what the original justification was about... |
dictionary RTCIceGathererIceErrorEventInit : EventInit {
RTCIceCandidate? hostCandidate;
DOMString url;
unsigned short errorCode;
USVString statusText;
}; If unreachable, the |
Great. |
We have defined
hostCandidate
as aDOMString
:But shouldn't it be the actual structure:
Seems it would be easier to correlate if we made an exact description.
Also, what would happen if there are no host candidates (privacy filter)?
The text was updated successfully, but these errors were encountered: