owt-server基本架构

第一块就是跟客户端进行信令交互的部件，即图中的WebRTC Portal和SIP Portal。他们跟WebRTC客户端和SIP终端进行信令交互。值得注意的一点是WebRTC标准对信令交互的格式和通道没有规定，采用的是一种承载在socket.io通道中的私有协议。

第二块是跟客户端进行音视频媒体交互的部件，即图中的WebRTC Agent、Streaming Agent、SIP Agent和Recording Agent。其中WebRTC Agent负责跟客户端之间建立PeerConnection连接，SIP Agent跟SIP终端RTP流进行传输，Streaming Agent是针对RTSP/RTMP/HLS/Dash流，我们可以把IPCamera的RTSP流作为输入直接拉到系统里面来，也可以把系统里面任何一个输入流/合成流/转码后的流作为输出推送到RTMP Server上去，Recording虽然是完全发生在服务器侧的行为，但实际上在概念层次上面是更接近于流的输出。所以在概念模型里我们也把Recording Agent当做媒体接出部件，以达到概念模型的一致性。

第三块是媒体处理的部件，即图中的Audio Agent和Video Agent。Audio Agent是进行音频混音转码工作的部件，Video Agent是视频的合屏和转码的部件，这些所有的部件都是单独部署独立进程在运行。

第四块是呼叫控制的部件，即图中的Conference Agent。我们的系统还是将多方实时音视频通信作为场景基础，Conference Agent就是一通呼叫的总控制部件，它负责room中的参与者、流、订阅关系的控制和管理。对于像远程教育、远程医疗、远程协助之类的其他场景，我们主要是通过对Conference Agent来进行拓展和增强去支持。

第五块就是一些支持部件。整个服务器系统在运行和单机运行时都是cluster形式，Cluster Manager就是一个简单的cluster管理器。视频会议场景中会有一些room的预配置和管理，room的配置数据存放在MongoDB中，管理员都是通过OAM UI通过RESTful API访问Management API部件实现数据访问并受理REST请求。另外各个部件之间的rpc是架设在RabbitMQ消息队列上的。