From 836dbf676ef05738299159a652e494ab75fc08a0 Mon Sep 17 00:00:00 2001 From: David Morales Date: Tue, 21 Dec 2021 11:45:23 +0100 Subject: [PATCH] Fix gravizo pictures. One of them is not fixable. The encoder tool (http://www.gravizo.com/#converter) fails to convert the diagrams unless you enable the extra compatibility flag. I have preserved the texts in a collapsible section, just for readability and edition purposes. One diagram is not fixable. It seems that the definition itself is not complete. --- feature-review/single-peer-connection.md | 45 +++++++++++++++++++----- 1 file changed, 36 insertions(+), 9 deletions(-) diff --git a/feature-review/single-peer-connection.md b/feature-review/single-peer-connection.md index 1484782139..6329b1ae34 100644 --- a/feature-review/single-peer-connection.md +++ b/feature-review/single-peer-connection.md @@ -38,7 +38,14 @@ Both Erizo Client and Erizo Controler might decide not to use Single PC for the In terms of message flow, current solution with Multiple Peer Connections is as follows: -![Multiple Peer Connections](http://g.gravizo.com/g? + + + + +
+ Diagram details @startuml; actor User; participant "Erizo Client" as Client; @@ -62,11 +69,19 @@ Client->EC: answer; Client<->EC: ICE Negotiation; Client<->EC: DTLS Negotiation; @enduml -) +
+ + + And with the new solution with Single Peer Connection it will be like the next figure: -![Single Peer Connection](http://g.gravizo.com/g? + + +
+ Diagram details @startuml; actor User; participant "Erizo Client" as Client; @@ -86,7 +101,8 @@ Client->EC: subscribe stream3; Client<-EC: Media Info; Client->EC: answer; @enduml -) +
+ ### How does it affect ErizoClient? Streams will be added to existing PeerConnections, and will need to keep track of the existing PeerConnections to decide whenever a user wants to publish/subscribe to a new Stream if we need to create a new Peer Connection or update an existing one. @@ -147,7 +163,12 @@ Much functionality inside WebRtcConnection will be moved to MediaStream. And Web Below I show a summary of the current architecture inside Erizo, with the main building blocks: -![Erizo Current Architecture](http://g.gravizo.com/g? + + +
+ Diagram details @startuml; WebRtcConnection<--OneToManyProcessor; DtlsTransport<--WebRtcConnection; @@ -158,11 +179,16 @@ WebRtcConnection : +onPacketReceived%28%29; OneToManyProcessor : +MediaSource publisher; OneToManyProcessor : +MediaSink subscribers; @enduml; -) +
And here we can see the proposal to change them: -![Erizo Proposed Architecture](http://g.gravizo.com/g? + + +
+ Diagram details @startuml; MediaStream<--WebRtcConnection; MediaStream<--OneToManyProcessor; @@ -177,8 +203,9 @@ OneToManyProcessor : +MediaSink subscribers; MediaStream : -Worker worker; MediaStream : -Pipeline pipeline; MediaStream : +onPacketReceived%28%29; -@enduml; -) +@enduml +
+ In summary, *WebRtcConnection will gather all MediaStreams* that receive/send data from/to the same DtlsTransport (connection). In Multiple Peer Connection cases there will be just one MediaStream per WebRtcConnection. Otherwise, there will be multiple MediaStreams. Finally, each *Stream will have its own Pipeline and Worker* to separate processing time and scale better to the number of streams per each connection.