kurento之WebRtcEndpoint到底是个啥

纵观 kurento-tutorial-java ，可以发现应用程序构建了大量的WebRtcEndpoint，那它到底是个啥呢？一言以蔽之，WebRtcEndpoint是webrtc协议的RTCPeerConnection(点对点连接)在KMS 中的代理对象。

对于 WebRTC 协议有一定了解的应该知道，在客户端A 和 客户端B 建立对等点连接时，需要用到 RTCPeerConnection 对象，完整的sdp协商流程如下：

1. 客户端 A 创建 RTCPeerConnection , 创建 sdpOffe, 将其发送给信令服务器；
2. 信令服务器将其发送给客户端B；
3. 客户端B在收到offer 以后，先将offer设置为远程描述，然后创建 sdpAnswer, 将其发送给信令服务器;
4. 信令服务器在收到 answer 时，将其设置为远程描述；

当然，完整的流程还包括 IceCandidate的交互 ，在创建 RTCPeerConnection 对象时，注册一个 onIceCandidate 事件，该事件能够获取到 IceCandidate ，将其发送给信令服务器，由信令服务器来转发给对等点；对等点在收到 IceCandidate 后，通过调用 addIceCandidate方法，将其添加到自己的候选人地址。具体的代码可以参考我的另一篇博文：WebRTC 之点对点连接。

如果我们需要在中间加一个流媒体服务器来转发我们的媒体流。应该怎么做呢？ KMS 在这方面抽象的很好，按照之前 客户端A和客户端B 建立连接，是如下形式：

那么我们在 加入了 kms 以后呢？变成了如下形式

多个WebRtcEndpoint 可以理解为当 客户端A与KMS 进行 sdp 协商时（通过信令服务器，以下sdp协商均是如此），我们将通过 api 来控制 kms 创建 WebRtcEndpoint 对象，这里将其命名为 WebRtcEndpointProxyA , 客户端 A 将与它协商建立对等连接，传输流媒体。对于客户端B 也是如此，将在KMS 中创建一个命名为 WebRtcEndpointProxyB（注意：我只是便于理解取了这样的名字） 的 WebRtcEndpoint对象。

那么 KMS 如何实现将 A的流媒体数据转发给 B的呢？ ，只需要设置 WebRtcEndpointProxyA 的接收端为 WebRtcEndpointProxyB ，设置WebRtcEndpointProxyB 的 接收端为 A ，这样就可以达到流媒体转发的过程，这个过程就很类似于未加入kms 的情况，不过少了 sdp 协商过程。并且 kms 还在引入了 管道的概念。更详细的内容参考这篇博文：Kurento API 解读

总结下，如果想要基于kurento 开发，当然是在api 上做文章了，也就是创建自己的应用程序，之前有见过信令服务器不应包含业务逻辑代码的说法，也就是说应用程序不应包含sdp的协商，不要问我为什么，因为那篇文章也没讲，我想的是可能为了防止这个应用程序过于复杂吧，毕竟协商是一个可以完全独立的过程，它也只在建立连接时有作用。理解了上面这个概念以后，建立自己的应用程序就简单多了（实际上也不会简单），流程上的控制还是很复杂的。