You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 25, 2024. It is now read-only.
* Add session ID for P2P.
* Add doc for perfect negotiation.
* Store only one PeerConnection for each remote endpoint.
* Implement polite peer and impolite peer for signaling.
* Implement perfect negotiation for WebRTC collision.
* Code cleanup.
* Listen to negotiation needed event.
Negotiation needed works good now, the SDK doesn't need to handle negotiation
needed flag manually.
* Address comments.
This document describes how perfect negotiation is implemented in OWT P2P SDK to avoid collision.
4
+
5
+
**Perfect negotiation**, **polite peer**, **impolite peer** are defined in [Perfect negotiation example of WebRTC 1.0](https://w3c.github.io/webrtc-pc/#perfect-negotiation-example).
6
+
7
+
## Determining polite peer and impolite peer
8
+
9
+
OWT client SDKs determines polite peer and impolite peer by comparing client IDs. Sorting these two client IDs alphabetically in increasing order, the first one is polite order, the second one is impolite peer.
10
+
11
+
Signaling server is required to return a client ID assigned to the client connected after authentication. OWT doesn't define how authentication works and how client IDs are assigned. They depend on application's design. But every client gets a unique client ID after connecting to the signaling server.
12
+
13
+
## Connections
14
+
15
+
We expect only one `PeerConnection` between two endpoints. A random ID is generated when creating a new `PeerConnection`. All messages (offers, answers, ICE candidates) for this `PeerConnection` have a `connectionId` property with the connection ID as its value. The connection ID is shared by both clients.
16
+
17
+
## Collision
18
+
19
+
When WebRTC collision occurs, it basically follows the perfect negotiation example in WebRTC 1.0. This section only describes the implementation for signaling collision.
20
+
21
+
A connection typically ends by calling `stop` at local side or receiving a `chat-closed` message from the remote side. Client SDKs stores the most recent connection IDs with all remote endpoints, and clean one of them when a connection ends. If the connection ID of a signaling message received is different from the one stored locally, collision happens.
22
+
23
+
An example is both sides call `send` to create a data channel and send a message to the remote endpoint at the same time. Each side creates a new `PeerConnection`, and a connection ID. These two connection IDs are different. Then each of them will receive signaling messages with connection ID differ from the local one.
24
+
25
+
### Polite peer
26
+
27
+
The polite peer is the controlled side. When a signaling message with a new connection ID is received, it stops current PeerConnection, create a new one, and associate it with the remote connection ID.
28
+
29
+
### Impolite peer
30
+
31
+
The polite peer is the controlling side. It ignores remote messages conflicting with its own state, and continues its own process.
this._publishedStreams=newMap();// Key is streams published, value is its publication.
@@ -91,13 +95,9 @@ class P2PPeerConnectionChannel extends EventDispatcher {
91
95
this._dataSeq=1;// Sequence number for data channel messages.
92
96
this._sendDataPromises=newMap();// Key is data sequence number, value is an object has |resolve| and |reject|.
93
97
this._addedTrackIds=[];// Tracks that have been added after receiving remote SDP but before connection is established. Draining these messages when ICE connection state is connected.
0 commit comments