openviduserver的webrtc通讯实现iv

a. 在openvidu中，一个激活的会议由kurentoSession实例表示。当创参会者加入会议时，openvidu会创建一个kurentoSession实例。
b. 在kurento服务器上，一个会议由一个pipeLine 和N N个mediaEndpoint表示。N表是参会方数量，每一个参会方会创建一个发布媒体用的MediaElement和(n-1)个订阅其它媒体流用的MediaElement，它们被编排入一个PepleLine中, 形成N N的连接。

所以，当第一个用户加入会议室时，系统会在Openvidu上创建一个KurentoSession实例，同时在Kurento上创建一个pipleLine, KurentoSession 实例引用了这个pipepline. N个用户会有N个kurentoSession, 但只有一个pipleline。PipleLine的描述是在Kurento Client包里。

管理器中另外一个重要的是sessionManager，session代表的是会议，所以sessionMananger 实际就是所有具体会议的管理. 在io.openvidu.server.core包下的SessionManager只是一个虚类，它声明了一些会议的操作方法：

这些方法都和会议有关， 可以发现，上面的功能通常对应我们音视频软件进入会议室的功能。

开openvidu中，它的具体的实现是KurentoSessionManager，它会在server启动的时候初始化。
在III中说了，sessionid 代表的会议号，创建会议的时候会创建一个sessionNotActive（Session类）对象，代表的是还未正式使用的会议，当第一个用户首次加入的时候，才会正式使用这个会议，KurentoSessionManager的joinRoom方法描述了相关的逻辑。
与sessionNotActive不同，一个开始使用的会议用KurentoSession来表示（继承自Session），首次加入会议， 需要创建这个Ksession, 它会指定一个具体的Kurrento Server，ksession的创建需要指定具体kms，用来表示在具体哪个KMS创建会议。社区版实际上只有一个KMS，但在实现上如下图， 已经默认使用获取最小负载的方式获得kms。

sessionManager对外提供会议操作功能的统一入口，每个会议对应的kurentoSession负责实际与kurento server的通信，来完具体的会议操作。所以在kurentoSession中我们可以看到相类似的会议功能定义：

上图是一个包含有浏览器、application 、 openvidu server, 、kurento server 等在内的一个逻辑通讯图。
浏览器端加载会议应用程序，通过http协议与application server通信，完成业务请求和获取用于会议的token和sessionID.
applicaiton server只负责业务请求，它通过与openvidu server通信来生成浏览器客户端加入会议需要的token和sessionID信息。
浏览器获取token和sessionid后，与openvidu建立websocket连接，它将openvidu作为webrtc中的singal server，与openvidu通信，完成建立webrtc所需要的singal通信。
与webrtc中描述的P2P通讯不同，kurento server 充当代理，与每一个参与方建立p2p连接，通过创建pipleline和编排media endpoint完成多方的通讯。 但是Kurento Server与任意参与方建立的通讯仍旧是P2P通讯。所以，浏览器会与kurento server建立webrtc连接。 他们的通讯默认是RTP over UPD, 也可以是RTP over TCP。
openvidu与kurento也是通过websocket连接进行通讯的，与kurento的通信包含两个方面：
a. 作为控制方，创建pipleline，根据加入的用户创建media endpoint, 并编排他们。
b。 作为信号服务器， 与Kurento进行webrtc连接时需要的信号通讯：例如发送sdp, icecandidate，sdp响应等，由于kurento并不是浏览器端，Sdp answser的创建，也是由openvidu完成的。
Openvidu与Kurento之间的通讯编码使用json RPC方式。 kurento 提供了client 包，方便opnvidu 实现rpc调用。

4.1 PipleLine
org.kurento.client包里包含一个pipleLIne类，它代表kurento server上的media pipleLine元素; 前面已经提到，一个会议对应一个kurencto pipleLine。而在openvidu中kurentoSession代表一个会议，它包含有一个pipleliene属性：
private MediaPipeline pipeline;
在首个用户加入会议的时候，会创建PipleLine实例：

查看createPipeline方法可以看到，pipleLine使用kurentoclient来创建的。
kms.getKurentoClient().createMediaPipeline(...)
PipleLine创建好一个,将作为会议的具体Rpc对象负责其它对象的创建和方法调用。

4.2 MediaEndpoint，publisherEndpoint、SubscriberEndpoint
openvidu里定义了一个个类：MediaEndpoint。 它对应的是kurento server上MediaElement的抽象，下图是Kurento上的元素概念：

在MediaEndpoint类中，定义了三个endpoint属性，代表三种连接类型：
···

···
WebRtcEndpoint 、RtpEndpoint 、PlayerEndpoint 这三个类来自kurent client包，代表JSonrpc的客户端类，在上图的kurento元素中能够找到对应的元素。
MediaEndpoint对三个类做了风中，使用endpointType来表示当前是那种类型（也就是哪个引用有值）。它有两个子类publisherEndpoint和SubscriberEndpoint，分别表示一个用于publish的mediaElement 和用于subscribe的mediaElement 。 在前文提到， openvidu的会议在kurento server上表示N*N 模型的media element关系, Server会为每一个参会者创建一个用于音视频发布的mediaElement 和(n-1)个用于订阅其它用户发布的音视频的media element，publisherEndpoint和SubscriberEndpoint对应的就是这个概念。
无论publisherEndpoint和SubscriberEndpoint是WebRtcEndpoint 、 RtpEndpoint，PlayerEndpoint中的哪个类型，它们封装的rpc对象都由 pipeline创建。

4.3 KurentoParticipant
openvidu中的KurentoParticipant类代表的是参会方（不同于我们平时理解的用户），每个用户加入会议后才会创建KurentoParticipant，在 "3.Openvidu Server与WebRTC的通信" 的示例图中表征的是一个浏览器与Kurento server的连接。一个用户可以打开多个浏览器页面，每个加入会议的页面实际上都代表一个KurentoParticipant。
KurentoParticipant没有具体的JsonPRC对象，相反它拥有一个PublisherEndpoint和
一组subscribers，它们在kurento server刚好表示一个会议参与方：

由于KurentoParticipant代表的是会议的参会方，这个类中定义了几乎所有与publisher和subscribers 有关的操作：

4.4 KurentoSession
KurentoSession 代表的是一个会议，在kurento上对应的是pipeline mediaElement，但它不属于JsonRPC对象，它对pipeline mediaElement的操作是由PipleLine Jsonrpc对象来完成的，所以它包含由pipeline属性：

这个类中定义了很多会议操作的方法：

浏览器客户端在创建连接获取token和session时，并不会直接创建KurentoSession，默认的只会创建一个session对象，并把它放在sessionNotActive组里。当用户Join会议的时候（调用 KurentoSessionManager.joinRoom(Participant participant, String sessionId, Integer transactionId) ），才会创建KurentoSession 实例。