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
RTCIceCandidateComplete dictionary #207
Comments
Sample code please (in |
Added the "failed" state to RTCIceTransportState, as noted in: Issue #199 Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue #200 Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in: Issue #207 Updated the description of RTCIceGatherer.close() and the "closed" state, as noted in: Issue #208 Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue #214 Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue #215 Clarified state transitions due to consent failure, as noted in: Issue #216 Added a reference to [FEC], as noted in: Issue #217
This seems kind of bizarre, an event with a variable that is only set to a single value. Can't this be handled entirely through IceGathererStateChange? |
We don't really need to generate RTCCandidateComplete at all because we know from the state, but how do we tell the remote RTCIceTransport that "candidates complete" is reached. We currently do that by adding this dictionary to "RTCIceTransport.addRemoteCandidate(candidateComplete)". |
Could we add a method that is effectively RTCIceTransport.expectNoMoreCandidates()? That might be more simple. Perhaps call it "RTCIceTransport.completeRemoteCandidates()" |
@pthatcher certainly can be done that way instead (think it's better). |
According to http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-addIceCandidate-Promise-void--RTCIceCandidate-candidate PeerConnection.addIceCandidate(IceCandidate) takes a non-nullable candidate. So going down the "overload addRemoteCandidate" path provides no similarity with WebRTC 1.0. That makes me more convinced we should go with a separate method of "RTCIceTransport.completeRemoteCandidates". But we should write some sample code to make sure what we're coming up with makes sense. |
This same issue existing in WebRTC 1.0 (which does not have a nullable candidate option to addIceCandidate in 1.0); Not sure how 1.0 even does this at all... |
IMHO that is valid as a network signaling fuideline and should not be defined by the spec. The very same can be achieved as follows: // Sender:
mySignaling.send('no more candidates');
// Receiver:
mySignaling.on('msg', function(data) {
if (data === 'no more candidates') {
iceTransport.completeRemoteCandidates();
}
} |
Currently there is a PR in WebRTC 1.0 to allow the null candidate as an argument to addIceCandidate(): It is awkward to have RTCIceCandidateComplete defined differently in WebRTC 1.0 and ORTC. |
@aboba If my memory serves me correctly, I believe it was Google who did not want to use "null" as an end of candidate scenario which is why we did the specialized "completed" candidate object. I don't personally care what we do but I prefer consistency. CC: @taylor-b @pthatcherg |
Well, in ORTC, an RTCIceCandidateComplete is emitted by onlocalcandidate and passed into addRemoteCandidate. And in WebRTC 1.0, null is emitted by onicecandidate and passed into addIceCandidate. So at least for both specs, the things that are emitted look the same as the things that are passed down. I prefer the RTCIceCandidateComplete approach, but with WebRTC there are applications depending on the "null" candidate for indicating the end of gathering, which is why we decided to leave it that way, since no one had strong opinions. Though if we end up deciding to trickle the ufrag/password (to resolve ICE restart ambiguities), we'll probably want to trickle that with "end-of-candidates" too, in which case it would need to become a dictionary. |
@robin-raymond There seems to be a preference for leaving the current RTCIceCandidateComplete definition alone. Can we close this issue or is there more to do? |
robin-raymond commentedMay 26, 2015
Testing for an empty object is not straight forward in JavaScript. It would be easier to add a name / value pairing like this when stringified:
{ "complete": true }
So we should have
complete
in theRTCIceCandidateComplete
dictionary which is mandatory and set totrue
.The text was updated successfully, but these errors were encountered: