Kurento应用开发指南(以Kurento 5.0为模板) 之五：kurento架构

11. Kurento 架构

和大多数的媒体通讯技术同样，Kurento把全部的交互通讯系统的关键功能抽象成两层(或平台):
?信令平台
系统中负责通讯管理的部分，它的组成模块提供的功能有媒体协商，QoS参数协商，呼叫创建，
用户注册，用户呈现等，都是信令层的功能；
? Media Plane 媒体平台
包括的功能包括媒体传输，媒体编码/解码和媒体处理，它关心的是媒体的处理。
它和电话的区别在于声音的处理以及媒体信息的处理，包括音调，响铃等。


下图显示了Kurento的高级系统架构。
 
Figure 11.1: Kurento 架构. 分红信令平台和媒体平台
上图的右边是应用服务器端，它负责信令平台，包含有业务逻辑和特定多媒体应用的链接。
它能够由像Java, Node.js, PHP, Ruby, .NET等任何一种编程技术实现。
应用服务端也可使用成熟的技术，像HTTP，SIP Servlet, Web服务，数据库链接，消息服务等。
能够这样认为，这一平台给终端提供了多媒体信令协议的访问接口，如SIP， RESTful，
和原始HTTP格式，SOAP， RMI, CORBA或JMS。这些信令协议被用于应用程序客户端，
用来命令要求建立媒体会话，并协商各类行为的特性。所以，它是架构的一部分，
用来和应用开发者交互。基于这个缘由，它的设计必须简单而灵活。


上图的左边Kurento媒体服务器，它实现了媒体平台功能，用以提供底层媒体功能的访问：
媒体传输，媒体编码/解码，媒体转码，媒体混合，媒体处理等。
Kurento媒体服务器必须具备以最小的延迟和最大的吞吐量管理媒体流的能力。
所以，Kurento必须对效率进行优化。

 

11.1 Kurento API和接口

媒体平台(Kurento媒体服务器)和信令平台(应用程序服务端)的能力是经过一系列API实现的，
它提供了愈来愈多的抽象级别。依据这个方式，不一样API的角色能够经过下面的方式来总结分类:
? Kurento 协议: 
它是将Kurento媒体服务器能力提供给WebSocket的网络协议。
? Kurento API: 
它是kurento协议的对象实现。这个API能够经过引用(ids)来建立和管理媒体元素和管道。
可使用大多数的编程语言或框架访问Kurento API。


? Kurento Java 客户端:
它是一个Java SE层，它用来消费Kurento API，
它经过一个基于Java POJO的简单易用并模块化表示媒体元素和媒体管道的方式暴露它的功能。
这个API的抽象了Kurento内部协议运做中全部非直观的复杂性，
使得开发人员在建立应用程序时，不须要处理这些媒体状况。
使用Kurento Java客户端只须要请求对maven项目添加一个合适的依赖并下载对应的jar包到应用程序开发者的CLASSPATH。
须要提醒的是，Kurento Java客户端只是一个媒体平台控制的API。
换句话说，它是目标是暴露管理媒体对象的能力，它并无提供任何信令平台的能力。


? Kurento JavaScript Client: 
它是一个JavaScript层，用来消费Kurento API并将其能力暴露给JavaScript开发者。
它能够用来建立node.js和浏览器的基本应用。在将来，会建立更多的Kurento客户端并以一样的模块的方式提供给其它语言，
如Python, C/C++, PHP等。


从架构的角度来讲，应用程序开发人员惟一要关心的是如何使用Kurento客户端
或Kurento API直接建立他们的多媒体应用程序。它为它的潜在应用场景打开了一个广阔的空间，
从页面应用(使用Kurento JavaScript客户端开发)， 桌面应用(使用Kurento Java客户端开发)，
分布式应用(使用Kurento协议开发).

 

11.2 Kurento 模块

Kurento设计实现了一个插件化的框架。
默认地，Kurento媒体服务器使用多个模块，命名为kms-core, kms-elements和kms-filters。
另外，Kurento媒体服务器还有一些内建模块来提高其能力，
这些模块分别是kms-crowddetector, kms-pointerdetector, kms-chroma, and kms-platedetector。
最后，Kurento媒体服务器还可使用定制化模块来扩展。
 
Kurento模块架构，Kurento媒体服务器可使用内建的模块(crowddetector, 
pointerdetector, chroma, platedetector)和定制模块来扩展。



 

11.3 使用Kurento建立应用程序

Kurento能够按照WWW的架构原则使用。也就是说，可使用建立网页应用程序的经验和框架来建立媒体应用。
在最高级的抽象层面上，网页应用架构由三个不一样的层构成:
? 表示层(客户端): 
在这一层上，咱们能够找到全部负责终端用户交互的应用程序代码，
所以，这些信息都要表示成用户能够理解的方式。它一般由HTML页面组成。


? 应用程序逻辑层(服务端): 
这一层负责给应用程序执行的指定功能的实现。


? 服务层(服务端或网络端): 
这一层提供应用程序逻辑须要使用的能力，应用程序逻辑包括数据库，通讯，安全等。
这些服务能够部署在同一台服务器，也能够由外部提供。


相似的，使用Kurento建立的多媒体应用也是以一样的架构实现:
? 表示层(客户端): 
负责媒体表示和媒体捕捉。它一般是基于客户端特定的内建的能力。
例如，咱们能够建立一个基于浏览器的应用程序，它的表示层可使用<video> HTML标签或WebRTC JavaScript API。


? 应用程序逻辑:
这一层提供了指定的媒体逻辑。换句话说，这一层负责建立合适的管道(经过连接但愿的媒体元素),
它包括应用程序须要都遍历到的媒体流。


? 服务层: 
这一层提供了用来支持应用程序逻辑的媒体服务，包括媒体录制，媒体加密等。
Kurento媒体服务器(如特定媒体元素组成的管道)负责这一层。


这个讨论有兴趣的方面在于，对WWW开发来讲，Kurento应用程序能够将表示层部署在客户端，
把服务层部署在服务端。然而，应用逻辑层，在这两种应用中，能够部署在这两端或分布式服务端，
以下图所示:
 
页面和媒体应用的层级架构。使用Kurento(右边)建立的应用程序和标准WWW应用(左边)相似。
两种类型的应用程序均可以将应用程序逻辑层部署在客户端或服务端。


这意味着Kurento开发者能够在客户端(使用合适的Kurento客户端或直接使用Kurento协议)
经过请求应用程序来建立指定的媒体管道，也能够部署在服务端。


上述这两个选择都是可行的，可是它们表明了不一样的开发风格。须要注意的是，
WWW开发者一般倾向于维护尽量简单的客户端，而将大多数的应用程序逻辑层部署在服务端。
Kurento一般也会复用这种经验而将媒体应用逻辑层部署服务端。
所以，能够为你想要的语言使用Kurento客户端来建立指定的媒体管道。


NOTE: 下面的章节是将Kurento的处理都部署在服务端，这是Kurento比较通用的方式。
但也能够把媒体逻辑在客户端使用 Kurento JavaScript Client实现。

 

11.4 客户端，服务端和Kurento的通讯

如上图所示，Kurento应用程序的交互在主要的三个模块之间:
? 客户端应用程序: 
它包括客户端平台原生的媒体能力加上指定的客户端的应用程序逻辑层。
它能够在客户端平台使用Kurento客户端(例如，Kurento JavaScript客户端)设计实现。


? 应用程序服务端: 
它包括一个应用程序服务端和服务端的应用程序逻辑层。
它能够在服务端平台使用Kurento 客户端(如Kurento Java Client for Java EE 
and Kurento JavaScript Client for Node.js)设计实现。


? Kurento媒体服务器:
它接收命令，用来建立指定的媒体能力(如指定的管道以适应于特定应用的须要)。


保持这些模块间的交互要视特定的应用程序而定。然而，一般来讲，大多数的应用均可以精简到以下的概念框架:


 
在架构模块间的主要交互。主要的交互分为两个阶段:协调和媒体交换。
不一样的箭头和颜色都有不一样的示意。红色的是和Kurento媒体服务器有关，绿色是和应用程序相关。


1. 媒体协商阶段 (信令)
如图所示，在第一步上，一个客户端(一个PC上的浏览器，或一个移动端应用等)
提交给应用程序一个消息来请求某种媒体能力。这个消息可使用任何协议(http, websocket, SIP等)实现。
例如，这个请求能够是对给定视频片段的可视化。


当应用程序收到这个请求后，若是合适，它将交付给指定的服务端应用程序逻辑层，
它包含身份验证，受权和统计(AAA)，CDR生成，某些Web服务的消费等。


这以后，应用程序处理这个请求，并依据由开发者指定的程序，
命令kurento媒体服务器实例化合适的媒体元素并组成合适的媒体管道。
当管道建立成功后，Kurento媒体服务器会回应给应用程序，应用程序会再回应给客户端。


上面的过程没有实际的媒体数据的交换。全部的交互都是协商要交换什么，
如何，在哪，何时的媒体。所以，咱们能够称之为协商阶段。所以，这个阶段只包含有信令协议。


2. 媒体交换阶段
上一阶段以后，新的阶段开始实现实际的媒体数据交换。
在协商阶段，客户端使用信息收集向Kurento媒体服务器发送了媒体请求。
正如上面提到的视频截图可视化示例中，浏览器将向Kurento媒体服务器的IP地址和端口发送一个GET请求，
在Kurento媒体服务器上能够得到这个截图，而后，就能够收到这个媒体的HTTP响应。


下面的讨论是和一个简单的例子相关，有些人可能会奇怪，为何如此复杂的主题只是为了播放一个视频，
在一些很常见的场景中，客户端只须要对视频的合适的URL发送一个请求就能够了，而不须要请求任何协商。
答案很简单，由于Kurento是设计为了包括复杂媒体处理的媒体应用程序的。
所以，咱们须要创建两个阶段的机制以使得在媒体交换以前有一个协商。
这样作的代价是，对于很简单的应用，即使以下载一个视频，也须要通过这两个阶段。


而后，它的优点是在建立更高级的服务时，这套一样简单的逻辑同样可行。
例如，若是咱们想对视频截图添加虚拟现实或计算机视觉功能，
咱们只须要在协商阶段选择须要的媒体元素就能够建立合适的管道来知足需求。
总之，从客户端角度来看，处理过的截图会和其它视频同样接收。

 

11.5 使用kurento实现实时WebRTC应用

Kurento能够在浏览器和Kurento媒体服务器间，经过使用WebRTC建立实时媒体会话。
另外，Kurento媒体服务器能够被用做媒体代理，以实现不一样客户端间的通讯，
它们都经过Kurento设备作为中转站。所以，Kurento媒体服务器能够用做会议桥(Multi-Conference Unit, MCU)，
如用在机器到机器的通讯系统，视频呼叫系统等。
As shown in the picture, the client exposes its media capabilities through an SDP 
(Session Description Protocol) sent in a request. Hence, the application is able
to instantiate the appropriate WebRTC endpoint, and to require it to generate a response 
SDP based on its own capabilities and on the offered SDP. When the answer SDP is obtained, 
it is given back to the client and the media
以下图所示，客户端经过SDP(Session Description Protocol)发请求来暴露其媒体能力。
所以，应用程序能够实例化合适的WebRTC终端，并请求以得到一个相应的SDP。
当得到SDP回答时，它就返回给客户端。
 
Main interactions in a WebRTC session. Interactions taking place 
in a Real Time Communications (RTC) session. During the negotiation phase, 
a Session Description Protocol (SDP) message is exchanged offering the 
capabilities of the client. As a result, Kurento Media Server generates 
an SDP answer that can be used by the client for extablishing the media exchange.


应用程序开发人员能够在协商阶段建立想要的管道，所以实时媒体流会依据应用须要被处理。
举例来讲，咱们相建立一个WebRTC应用程序来录制从客户端收到的媒体流并判断其中是否有须要寻找的人脸，
而且找到人脸后就会给他戴上一顶帽子。这个管道的主体框架以下图所示，
其中咱们假设滤镜元素能够进行面部识别并添加一顶帽子。
 
Example pipeline for aWebRTC session. During the negotiation phase, 
the application developer can create a pipeline providing the desired specific functionality.
For example, this pipeline uses a WebRtcEndpoint for communicating with the client, 
which is connected to a RecorderEndpoint storing the received media streamd and to 
an augmented reality filter, which feeds its output media stream back to the client. 
As a result, the end user will receive its own image filtered (e.g. with a hat added onto her head) 
and the stream will be recorded and made available for further recovery into a repository (e.g. a file).
一个WebRTC会话的示例管道。在协商阶段，应用程序开发人员能够建立一个管道来提供想要的功能。
例如，这个管道使用WebRtcEndpoint 来和客户端通讯，
同时，它还链接有一个RecorderEndpoint 用来存储收到的媒体流，
对于一个加强现实滤镜来讲，它将媒体流返回给客户端。
结果是，终端用户将收到它本身的图像滤镜(如添加帽子的头像)而且流被纪录到了存储系统并能够为之后使用。

 

11.6 Kurento 设计原则

Kurento的设计基于下面的原则:
Separate Media and Signaling Planes 
独立的媒体和信令平台
Signaling and Media are two separate planes and Kurento is designed 
so that applications can handle separately those facets of multimedia processing.
信令和媒体是两个独立的平台，Kurento设计成这样是为了应用程序能独立地进行媒体处理
Distribution of Media and Application Services 
分布式的媒体和应用服务
Kurento Media Server and applications can be collocated, scalated or distributed among different machines.
A single application can invoke the services of more than one Kurento Media Server. The opposite
also applies, that is, a Kurento Media Server can attend the requests of more than one application.


Suitable for the Cloud 
适合于云处理方式
Kurento is suitable to be integrated into cloud environments to act as a PaaS
(Platform as a Service) component.


Media Pipelines 
媒体管道
Chaining Media Elements via Media Pipelines is an intuitive approach 
to challenge the complexity of multimedia processing.


Application development
应用程序开发
Developers do not need to be aware of internal Kurento Media Server complexities, 
all the applications can deployed in any technology or framework the developer like, 
from client to server. From browsers to cloud services.


End-to-end Communication Capability 
端到端的通讯能力
Kurento provides end-to-end communication capabilities so
developers do not need to deal with the complexity of transporting, encoding/decoding and rendering
media on client devices.


Fully Processable Media Streams 
彻底可处理的媒体流
Kurento enables not only interactive interpersonal communications
(e.g. Skype-like with conversational call push/reception capabilities), but also human-to-machine
(e.g. Video on Demand through real-time streaming) and machine-to-machine (e.g. remote video
recording, multisensory data exchange) communications.


Modular Processing of Media 
模块化的媒体处理
Modularization achieved through media elements and pipelines allows
defining the media processing functionality of an application through a “graph-oriented” language,
where the application developer is able to create the desired logic by chaining the appropriate functionalities.


Auditable Processing
Kurento is able to generate rich and detailed information for QoS monitoring,billing and auditing.


Seamless IMS integration 
Kurento is designed to support seamless integration into the IMS infrastructure of Telephony Carriers.


Transparent Media Adaptation Layer 
Kurento provides a transparent media adaptation layer to make the convergence among 
different devices having different requirements in terms of screen size, power consumption, 
transmission rate, etc. possible.