Kurento架构

参考 kurento architecture

架构

信令部分 和 媒体部分

Kurento架构，信令和媒体层

• 信令层: 提供媒体协商能力、QoS参数化、呼叫建立、用户注册、用户显现等的一些模块组成了信令层。（The parts of the system in charge of the management of communications, that is, the modules that provides functions for media negotiation, QoS parametrization, call establishment, user registration, user presence, etc. are conceived as forming part of the Signaling Plane.）
• 媒体层： 媒体支持、编解码和媒体处理等组成了此层...（Functionalities such as media transport, media encoding/decoding and media processing make the Media Plane, which takes care of the handling of media. The distinction comes from the telephony differentiation between the handling of voice and the handling of meta-information such as tone, billing, etc.）

Kurento接口

• Kurento协议：websocket
• Kurento API：是从面向对象的角度使用kurento协议.
• Java 和 JS 客户端： 简化API使用， 分别可以在Java服务端、 NodeJS、浏览器里实现和KMS的交互

Kurento模块

插件式的模块， KMS默认使用模块：kms-core, kms-elements, kms-filters。其他增强型的模块如：kms-crowddetector, kms-pointerdetector, kms-chroma, 和 kms-platedetector。
用户可通过自定义模块扩展其功能。

模块构架，可使用内置模块扩展功能，也可开发自定义模块

使用Kurento创建应用

• 展现层（客户端）：负责媒体的展现和抓取
• 应用逻辑层：负责媒体业务逻辑。具体说， 这一层要通过控制KMS连接媒体组件Media Elements 创建恰当的媒体管道pipeline， 让相关的媒体流从中通过
• 服务层：为了支持业务层， 负责媒体的处理，如媒体录制、加密等，具体说就是KMS

可将展现层放在客户端， 服务层放在服务端， 业务逻辑层放二者之一即可：

核心的两部分交互：媒体协商和媒体交换

一般为了简化客户端，业务逻辑层放在服务端。当然也可以使用如 Kurento JavaScript Client将业务层放在客户端。

客户端、服务端及Kurento的交互

web和多媒体层架构

1. 媒体协商阶段（信令）

如上图所示，在第一阶段，客户端向应用服务请求某种媒体能力，此过程可使用任何协议（http, websocket, SIP等）。

当应用服务接到请求，可以执行其业务逻辑，可包括AAA：认证（Authentication）、授权（Authorization）和计费（Accounting）， CDR阶段和web服务调用等

之后，应用服务端根据开发自定义的指令决定如何通过媒体组件连接来创建一个pipeline，一旦KMS创建成功pipeline，应用服务将成功消息发送给客户端，告知怎样以及去哪（How and Where）获取媒体服务。

字啊以上的过程中都没有媒体数据（media data）真正交换， 所有的交互都是在协商媒体交换的问题：什么、何时、何地、怎样（whats hosts wheres and whens）。所以称为协商阶段， 显然此阶段之保护指定协议。

2. 媒体流交换阶段

媒体协商过后， 真正专注于媒体数据的交换。客户端使用在协商阶段获取的信息，向KMS获取媒体数据。

使用Kurento做实时WebRTC应用

Kurento允许浏览器建通过WebRTC建立实时媒体会话。另外，可使用KMS作为不同客户端间交互的媒体代理。所以KMS可以扮演会议桥接（conference bridge (Multi-Conference Unit, MCU)）、端到端通信系统（machine-to-machine）、视频呼叫录制系统等（ video call recording system）。

如下图，客户端通过SDP暴露自己的媒体嗯嗯管理，因此，应用服务能够实例化恰当的WebRTC端点(endpoint)，请求KMS，KMS基于自身的和客户端的媒体能力生成相应的SDP回应， 客户端获取到回应后开始媒体数据交换。总结为下图：

在WebRTC会话中的主要交互

应用开发者可在媒体协商阶段根据需要创建pipeline，如：创建一个WebRTC应用录制客户端音视频，并且在识别到人脸时给戴上一个帽子：

pipeline示例

Kurento设计原则：

• 媒体和信令分离
• 媒体和应用服务可分布式水平扩展
• 适合于云 PaaS
• 媒体管道 Piplines
• 对应用开发友好：屏蔽了KMS的复杂性，可用任何平台和语言
• End-to-End的交流能力：开发者不用处理媒体编解码、传输和渲染等复制事宜
• 可全权处理的媒体流：不止普通软件（如Skype）人与人交流，可实现人与机器、机器与机器之间的交流。
• 过程可监控：可为QoS监控、账单、审计等生成丰富详细的信息
• 无缝的IMS（IP Multimedia Subsystem）集成
• 透明的媒体适应层：使得不同设备（屏幕尺寸、耗电能力、传输速率等）的会聚成为可能