-
Notifications
You must be signed in to change notification settings - Fork 8
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
RTCIceCandidate format #28
Comments
I agree. The |
ORTC:
WebRTC:
It looks like WebRTC uses the candidate string together with sdpMid and/or sdpMLineIndex to create an RTCIceCandidate object. In ORTC you construct that object directly. From the spec I did not really understand what the |
Let's just send the whole RTCIceCandidate instance as defined above as a generic JSON object (serialised to a MessagePack map on the wire and unserialised to a generic JSON object before it's being passed to an |
Ok, so this would be the RTCIceCandidate?
|
Nearly. We'll also send the fields |
Well, but what if both If it's easy to deduce the |
I'm with you - yes, the information is redundant. But you can't reconstruct an RTCIceCandidate instance without For us, another option would be to just send |
That would probably be the best approach for now. The implementors know which library they want to use :) |
The spec for the candidate message is as follows:
That assumes that the candidates are sdp strings. In the WebRTC
RTCIceCandidate
structure, that is contained in thecandidate
string attribute. On the other hand, ORTC does not provide such an attribute: http://ortc.org/wp-content/uploads/2015/06/ortc.html#h-rtcicecandidateCan we simply send the entire
RTCIceCandidate
structure instead? Or is that too implementation-specific? Maybe we can define a key mapping?The text was updated successfully, but these errors were encountered: