This is an old revision of the document!
Signaling
working out an example with 2 clients trying to connect
- There has to be some sort of server outside of the ICE server that handles the signaling
- The clients need some way to identify themselves on the signaling server so there is typically a login process. This is not required though.
- The signaling server is typically accessed through websockets
- Part of the point is to agree on an ICE server?
- Signaling follows a protocol called SDP (Session Description Protocol). Looks something like:
Caller Signaling Server Target Peer "type": "offer", "offer": { "sdp": "v=0\r\n...", "type": "offer" }, "name": "userB" ---------------------> "type": "offer", "offer": { "sdp": "v=0\r\n...", "type": "offer" }, "name": "userA" ---------------------> "type": "answer", "answer": { "sdp": "v=0\r\n...", "type": "answer" }, "name": "userA" <--------------------- "type": "answer", "answer": { "sdp": "v=0\r\n...", "type": "answer" } <--------------------- "type": "candidate", "candidate": { "candidate": "candidate:842163049 1 udp 1677729535 192.168.1.2 56143 typ host", "sdpMid": "0", "sdpMLineIndex": 0 }, "name": "userB" ---------------------> "type": "candidate", "candidate": { "candidate": "candidate:842163049 1 udp 1677729535 192.168.1.2 56143 typ host", "sdpMid": "0", "sdpMLineIndex": 0 }, "name": "userA" --------------------->
- candidate exchange goes back and forth between the caller and the target until they agree * the
“sdp”: “v=0\r\n…”,
stuff is about agreeing on what protocols, types of messages, etc. And SDP is currently at version 0 * the tutorialspoint example does not use the “name” label when negotiating candidates. Is that because the offer and answer have already happened so both clients know the other client is the one offering the candidates? *