Comments (8)
I agree. The RTCIceCandidate
interface should be pretty fixed - I'm not expecting any changes to it for either WebRTC or ORTC. However, they should be treated as individual types.
Also, we want to be independent from the browser's implementations. Thus, the MessagePack serialisation must be crystal clear in the protocol spec.
from saltyrtc-meta.
ORTC:
dictionary RTCIceCandidate {
DOMString foundation;
unsigned long priority;
DOMString ip;
RTCIceProtocol protocol;
unsigned short port;
RTCIceCandidateType type;
RTCIceTcpCandidateType tcpType;
DOMString relatedAddress = "";
WebRTC:
dictionary RTCIceCandidateInit {
required DOMString candidate;
DOMString sdpMid;
unsigned short sdpMLineIndex;
};
[ Constructor (RTCIceCandidateInit candidateInitDict)]
interface RTCIceCandidate {
readonly attribute DOMString candidate;
readonly attribute DOMString? sdpMid;
readonly attribute unsigned short? sdpMLineIndex;
readonly attribute DOMString foundation;
readonly attribute unsigned long priority;
readonly attribute DOMString ip;
readonly attribute RTCIceProtocol protocol;
readonly attribute unsigned short port;
readonly attribute RTCIceCandidateType type;
readonly attribute RTCIceTcpCandidateType? tcpType;
readonly attribute DOMString? relatedAddress;
readonly attribute unsigned short? relatedPort;
serializer = {candidate, sdpMid, sdpMLineIndex};
};
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 sdpMid
and sdpMLineIndex
do. But we could probably choose the same structure as ORTC and then construct the candidate
string from that in WebRTC?
from saltyrtc-meta.
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 onCandidate
event) and leave it up to the users which fields they want to use to reconstruct the RTCIceCandidate. The SDP-stuff is not really well explained because it's not meant to be modified and... I don't really understand it either. (Personally I think SDP is an unnecessary burden - that's why I like ORTC.)
from saltyrtc-meta.
Ok, so this would be the RTCIceCandidate?
interface RTCIceCandidate {
foundation: string,
priority: number, // unsigned long
ip: string,
protocol: 'tcp' | 'udp', // RTCIceProtocol
port: number, // unsigned short
type: 'host', 'srflx', 'prflx', 'relay', // RTCIceCandidateType
tcpType?: 'active' | 'passive' | 'so', // RTCIceTcpCandidateType
relatedAddress?: string,
relatedPort?: number, // unsigned short
}
from saltyrtc-meta.
Nearly. We'll also send the fields candidate
, sdpMid
and sdpMLineIndex
in case WebRTC is being used.
from saltyrtc-meta.
Well, but what if both candidate
and the other fields are filled out with conflicting information? Which one is authoritative?
If it's easy to deduce the candidate
from the fields above, I don't think we should include redundant information.
from saltyrtc-meta.
I'm with you - yes, the information is redundant. But you can't reconstruct an RTCIceCandidate instance without candidate
, sdpMid
and sdpMLineIndex
(see the RTCIceCandidate interface constructor). At least not for WebRTC.
For us, another option would be to just send candidate
, sdpMid
and sdpMLineIndex
for WebRTC and the well defined RTCIceCandidate interface for ORTC (which is also slightly different to the one that WebRTC defines).
from saltyrtc-meta.
That would probably be the best approach for now. The implementors know which library they want to use :)
from saltyrtc-meta.
Related Issues (20)
- Specify recommended exchange message HOT 4
- Post-Release-List HOT 7
- Handover Data Race HOT 1
- End of Candidates HOT 16
- Handover Disable Request HOT 3
- Inconsistency regarding handling of inactive responders HOT 3
- Candidates message example needs update
- Maximum message size can be dropped
- Maximum message size is u64 and may be 0 HOT 1
- ufrag renamed to usernameFragment HOT 1
- onIceCandidatesRemoved HOT 5
- Explain Identity HOT 2
- Accepting message sources other than 0x00 HOT 2
- Msgpack type for binary data HOT 2
- Non-binary websocket messages HOT 1
- Remove send-error message HOT 4
- What is close code 3003 "Handover of the Signalling Channel" being used for? HOT 2
- SaltyRTC and Verifpal HOT 2
- Questions about the protocol HOT 11
- Inconsistency (or unclear text) wrt. closing with an authenticated client. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from saltyrtc-meta.